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

tomrey

Sorry for my "expecting" misformulation (coming from spanish "esperando"="waiting for").
I am absolutely aware of volunteer, no cost etc. but I do share your valuation of the actual situation.
Not being a programmer and given the fact that it was working to my remembering until sometime in 2025 I think it should be possible to go back to the previous versions to find the last working one. Am I wrong?

phaze75

tomrey Sorry for my "expecting" misformulation (coming from spanish "esperando"="waiting for").
I am absolutely aware of volunteer, no cost etc. but I do share your valuation of the actual situation.

Thanks for your clarification.

tomrey Not being a programmer and given the fact that it was working to my remembering until sometime in 2025 I think it should be possible to go back to the previous versions to find the last working one. Am I wrong?

It is still not entirely clear where this issue actually originates, which is why support from the TVH developers would be highly appreciated.

Based on my own conclusions, the issue appears to have been triggered by ORF’s change in encryption from CryptoWorks to Irdeto around mid-2025. There was a transition period during which both systems operated in parallel, so it is unclear when it happend exactly. Whether ORF also changed anything else related to their regional broadcast streams remains unknown. My support request to ORF resulted only in a vague, non-technical response.

More recently, our issue analysis has shifted away from the assumption that this is purely a decryption-layer problem. Instead, it now seems more likely that the root cause lies in TVH’s streaming layer, which appears to be less robust than VLC’s. VLC was - and still is - able to handle the switch from national to regional broadcasts and back with only minor glitches, but without crashing. This hypothesis is further supported by @Sp3ncMan’s workaround, which - to my understanding - essentially wraps the stream with VLC and bypasses the corresponding TVH component.

From my perspective, we have already narrowed the issue down significantly, but we are still missing the definitive explanation of what exactly causes it.

To answer your question: I’m afraid simply rolling back the TVH code to mid-2025 is unlikely to solve the problem. I suspect this is a long-standing TVH bug that only became visible due to ORF’s change in encryption and potentially other unknown changes to their broadcast stream. Anyway, VLC holds the proof that the stream can be properly processed.

tomrey

I am observing that during a recording of ORF, swiching between crypted and non crypted signals works as expected.
Additionally I observe that since the change (which so ever) normal tuning to an ORF-channel takes by far longer than previously. I had to change the fault tolerance parameter to get it work at all. It fails mostly 3 times and then tunes properly. The fault occurs here as well for scheduled recordings where no streaming is involved. I cannot view faulty recorder files with VLC. In my eyes this speaks against the streamin theory. Probably this info may help.
Has anyone already tried to go back to the previous versions?
I would like to try but working with synaptic I can only go foreward...

Pablo R.

Hello guys, could you provide a new ts dump? The one from @DeltaMikeCharlie seems expired.

DeltaMikeCharlie

Pablo R. Hello guys, could you provide a new ts dump?

The free service that I use only retains uploads for 7 days. Here is a fresh upload:

https://limewire.com/d/DEp58#Uk1yu7L2Ji

Also, has anyone tried contacting ORF? Perhaps one solution would be to encrypt both the regional and national programmes using the same method. The PIDs would still change, however, the encryption would stay the same.

I'm sorry if this idea makes no sense, in Australia, we simply don't have encrypted regular broadcast services like this.

phaze75

Pablo R. Hello guys, could you provide a new ts dump?

Unfortunately, I don't know how to create a dump that is not encrypted. If you can tell me how, anytime!

DeltaMikeCharlie Here is a fresh upload:

Thanks for stepping in again.

DeltaMikeCharlie Also, has anyone tried contacting ORF? Perhaps one solution would be to encrypt both the regional and national programmes using the same method. The PIDs would still change, however, the encryption would stay the same.

I'm sorry if this idea makes no sense, in Australia, we simply don't have encrypted regular broadcast services like this.

I already contacted ORF but my support request resulted only in a vague, non-technical response. Still, I'd reach out to them again once we’ve clearly identified the issue and can point them directly to what they would need to do on their end. Their communication is very slow and unresponsive, so I'm afraid being too unconcise will lead us nowhere.

tomrey

I have not found any difference in the behaviour between national and regional ORF-programs. My official decryption-card is several years old and I was never informed by the provider about any change. Using the card in an normal android-tv doesn't show any faults. So for me its either the OS (Debian trixie) or THV. Have a nice sunday!

phaze75

ORF Digital - WICHTIGE INFORMATIONEN ZUM EMPFANG MIT ORF-KARTE

The ORF transition from CryptoWorks to Irdeto was already started in 2009 and ended in 2025 (the sale of dual encryption smartcards already ended in 2024). See weblink above. So, between 2009 and 2024 the ORF smartcards contained the keys for both encryption systems. Personally, I used CryptoWorks until mid 2025 before I manually switched to Irdeto. However, the issue didn’t start directly after my switch, that would be too easy. Further, I also had some issues from time to time with the regional/national switch while still using CryptoWorks. However, the crashing stream only happened after my switch to Irdeto which still might be just a coincidence and unrelated to Irdeto or the decryption system in general. We simply don’t know yet.

Sp3ncMan

Hi all!

My workaround is good-working, transparent and beautiful, but it's only a "work" "around", and it will never replace a patch. Use this workaround and enjoy if you want. My code can be used of course, I will also help with configuration!

I think that getting a developer who is familiar with that part of code AND who is familiar with the satellite technology behind, is nearly impossible nowadays. 80% of people I know do not have TV receivers at home - only streaming! Conventional TV is unfortunately dying.

Main Problem #1 with debugging:

a TS dump is very limited useful, because irdeto is based on time and date, and deny old stream decryption. So debugging under this circumstances is hard, you have only one chance a day to debug. AND the debugger has to be Austrian or at least to have some Irdeto hard- and software.

I have made debugging with Github Copilot Pro for 4 months, nearly every day. Besides numerous rubbish Copilot tells me, we found out, that the result of the problem is a missing SMT_START in HTSP protocoll. WHY this SMT_START is missing, and the stream on Kodi client therefore do not start anymore, I do not know. We patched so much functions to find out where the problem is, but without success, sorry!!

If I can anything do to help with this - anytime!!!

Mario

DeltaMikeCharlie

Sp3ncMan we found out, that the result of the problem is a missing SMT_START in HTSP protocoll.

Have you tried configuring your Kodi HTSP Client to use HTTP streaming?

Or even using VLC as the client because it only streams using HTTP.

If HTTP steaming works OK, then we can confirm that the issue is confined to HTSP, or Kodi as the client.

I'm not sure how the HTSP client will behave if it is sent a subscriptionStart message in the middle of an existing stream. Perhaps a subscriptionSkip message could be used to reset the client.

https://docs.tvheadend.org/documentation/development/htsp/server-to-client-methods#subscriptionstart

Sp3ncMan

DeltaMikeCharlie

Yes, I've tried this of course, and switching to HTTP always works! Bug seems to be limited to HTSP only. This is why my workaround works, I grab the stream before HTSP layer with VLC as a webplayer, and bring it back to to TVH with virtual MUX.

By the way: an unencrypted TS file with PMT changes should also reproduce the problem. Debugging should be much easier with this. But I haven't tried it.

In Detail: when it comes to an switch, TVH logs a PMT_UPDATE with "stream_delete/new_stream", Kodi cancels the connection and makes a new abo, but TVH sends no "SMT_START" or "subscription_start" packets. This also occurs if you make a Stop in Kodi and Start again. So Kodi never starts the stream because TVH never says to do it.

DeltaMikeCharlie

Sp3ncMan This also occurs if you make a Stop in Kodi and Start again.

Can you please provide more details on how to reproduce this?

« Previous Page