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...

phaze75

Sp3ncMan we both are on the same direction ;-)

Yes indeed! ;-)

Sp3ncMan What I can say is, that timeshift is not working with pass-profile any more :-(

These are just troubleshooting steps to pinpoint the root cause of the issue. I don’t plan to use “http” streaming or the “pass” profile as a long-term fix. There’s a reason “htsp” is the standard for TVH.

phaze75

One more thought - since the VLC client could keep streaming via HTTP, this means also the full decryption process was working. So I’m assuming the decryption itself isn’t the root cause, especially as I noticed that oscam kept decrypting even the “gone-dark” subscription for the Kodi client. The issue might be on the subscription layer.

Sp3ncMan

phaze75 exactly!

Sp3ncMan

seems to be very similar, what do you mean?
https://old.tvheadend.org/issues/4361?tab=notes

phaze75

Sp3ncMan seems to be very similar, what do you mean?
https://old.tvheadend.org/issues/4361?tab=notes

This issue seems to be quite similar, with the difference being that the current one is caused by switching streams on the broadcast side.

DeltaMikeCharlie 1) Streaming results seem to depend on the client and/or the protocol in use.
2) TVH sees the change in the DTS, tries to compensate (tsfix messages), but does not totally succeed. Perhaps the DTS change is too large to handle.

@DeltaMikeCharlie Since this issue from eight years ago shows striking similarities to our current one and seems to align with your two findings, would it make sense to compare the root cause and coding solution with our current issue?

DeltaMikeCharlie

phaze75 Since this issue from eight years ago shows striking similarities to our current one and seems to align with your two findings, would it make sense to compare the root cause and coding solution with our current issue?

I'm not sure. Looking at the file from 8 years ago, it is VERY different to the current version. Here is the change referenced as fixing the previous issue.

tvheadend/tvheadend6833091

phaze75 The old issue also shows the "0 kb/s output" symptom for "htsp" subscriptions, while "http" subscriptions work.

I can't remember if I looked at the output statistics during my tests. The fact that Kodi did eventually restart suggests that perhaps data was still flowing.

phaze75

phaze75 Here’s where it gets interesting:

It’s clearly not the stream itself causing the issue, but rather the subscription of each client. While VLC keeps playing on the same stream shared by the Kodi clients, the latter go dark. The screenshot shows that the Kodi subscriptions still receive the correct input bandwidth but have zero output bandwidth (see red boxes), whereas the VLC subscription maintains proper output bandwidth.

Sp3ncMan EDIT: also strange when tuning with kodi: no output traffic under subscription

The old issue also shows the "0 kb/s output" symptom for "htsp" subscriptions, while "http" subscriptions work.

Sp3ncMan

DeltaMikeCharlie You mean the problem is totally client dependent in your opinion?

Sp3ncMan

DeltaMikeCharlie You mean the problem is totally client dependent??

In my opinion, its only indirect client dependent. Look at your screenshot, the difference between Kodi and VLC is the profile and the way the stream is build internally:

Kodi: uses HTSP with timeshifting and ts-fix.
VLC: uses pure TS stream without any modification from within TVH.

My supposition is, that there is somewhere a logical problem or a bug in these kind of functions which are working around HTSP profile.

Sp3ncMan

What I have tried today: new Ubuntu 24.04 Server with cloned git from TVH, compiled and basic setup with oscam. Played it with Kodi and the stream stays OK.

What I have to try next time: switch ON timeshifting (was off)

Versions: 4.3-2528_g0b23983f5

boern99

This can not be client dependend only: Recording is also dark after the Switch and it is not possible to start a new recording, even if there was no client connected in this timeframe.

« Previous Page