ORF 2 Stream Crash on TVH Server

phaze75 · 2025-10-08T18:42:25+00:00

Hi there, For the past few weeks, I’ve been experiencing an issue with the ORF 2 channel stream provided by the Austrian Broadcasting Corporation. This chan...

Florian

Hey there!

Until the official fix is merged and released, piping the stream via FFmpeg or VLC in a new Pipe Mux works for me as a clean workaround (e.g., for ORF 2 V).

Option A (FFmpeg):
pipe:///usr/bin/ffmpeg -loglevel fatal -i "https://IP/stream/service/0456c80275b8eb65d2c821fea32abb6d" -c copy -f mpegts pipe:1

Option B (VLC):
pipe:///usr/bin/cvlc --quiet "https://IP/stream/service/0456c80275b8eb65d2c821fea32abb6d" --sout '#std{access=file,mux=ts,dst=-}'

Both methods run smoothly without glitches or crashes, keep resource usage minimal, and don't require installing or tweaking Python. Nevertheless, I haven't done proper and full testing.

Setup:
Ubuntu 24.04.5 on Raspberry Pi 5 (8G)
tvheadend 4.3-2811_gf58262e2c as system service, DVB-S via digibit twin and OSCAM
vlc 3.0.20 on system
ffmpeg version 6.1.1-3ubuntu5+esm13 on system

Possible improvements:

Gemini 3.6 proposed some additional arguments to reduce delays and speed up reconnects, but I haven't tested these yet.

Do you see any downsides?

Bernhard Berger

An update to my posts above: we have since been running PR #2206 in production and tested it in more detail.

Our setup (native Debian 13, OctopusNET SAT>IP, OSCam) has run a build with the PR since early September. The daily ORF2 regional switches no longer leave HTSP clients with a dead stream.
We also built a replay test from real recordings of the switch. Plain master lost the live stream at every switch (8 of 8 runs). With the PR the stream came back every time, after about 1 to 1.5 seconds. Recordings and timeshift across the switch worked as well.
Along the way we found a few smaller problems around PMT changes and sent fixes as separate PRs (#2306, #2307, #2308).

The details and numbers are in the PR, along with a test build that includes the PR and those fixes: tvheadend/tvheadend2206

@Florian about the pipe workaround: we haven't tried it ourselves. It gets around the problem because ffmpeg or VLC writes a new transport stream, so tvheadend never sees the PID change. The cost is an extra process and some added delay per channel, and ffmpeg or VLC decide which streams make it through the switch, for example whether the extra audio tracks come back afterwards. As a stopgap until #2206 is merged it seems fine.

« Previous Page