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

DeltaMikeCharlie I am starting to think that the problem is related to the change in encryption, not the change in programme PIDs.

That's what I suspect too. It would also fit to the fact that the issue became (more) virulent after ORF's recent change from Cryptoworks to Irdeto.

This makes me wonder if it would be helpful to log one or some of those subsystems:

DeltaMikeCharlie If TVH was unable to handle the change in PIDs alone, my test should have frozen at the join.

From what I understood, PID changes are common during stream switches, so if TVH couldn't handle these changes, it would likely affect a lot more users. This further supports the idea that it might be linked to the encryption system.

phaze75

boern99 regional timeframe 18:59-19:25

Please note that the switch might occur well before or after the official program schedule. To be safe, the mux dumps should cover 18:50-19:00 and 19:20-19:30 - on weekdays, the weekend schedules are different, because regional programs are usually shorter and vary in length.

phaze75

DeltaMikeCharlie What would be really helpful is full mux dumps that capture each transition. The other mux dumps that I have seem to be before and after the transition, but not showing the actual transition.

I am absolutely sure that this mux dump, which I shared five days ago, shows the actual transition from national to regional: https://www.transfernow.net/dl/20251027Z4fgZaFB

boern99

Two services for one channel: ORF2W and ORF2S could still be a workaround:
Today, automatic recover after the regional time frame worked using the api and cronjobs to set the priority of ORF2W lower than that of ORF2S during the regional time frame …
I will test this and adjust it as needed in the coming days.

DeltaMikeCharlie

I got a decrypted "ORF2St_HD" stream from an undisclosed source.

I can play the stream in VLC without a problem. At the national/local transition, there is a small glitch in the picture and sound, but otherwise the stream keeps playing.

When I feed the stream into TVH as a mux dump, the stream works up until the national/local transition, it then has a glitch and plays for a few more seconds before the stream dies.

I was watching the PIDs in the Status/Streaming screen and I briefly saw more PIDs appear before the stream stopped.

In the log, I can see that the transition is recognised, but I then get lots of decryption messages as the stream fails.

2025-11-02 10:57:05.747 [  DEBUG]:tbl-base: pmt: Service "TSfile Network/Multiplex [onid:0001 tsid:03ED]/ORF2St HD" PMT (version 12) updated, PCR PID changed, New elementary stream, Stream deleted, Language changed, Audio type changed

2025-11-02 10:57:31.885 [  DEBUG]:tbl-base: pmt: Service "TSfile Network/Multiplex [onid:0001 tsid:03ED]/ORF2St HD" PMT (version 14) updated, PCR PID changed, New elementary stream, Stream deleted, Language changed, Audio type changed

*** Here TVH sees the encryption change.
2025-11-02 10:57:40.241 [  DEBUG]:tbl-base: pmt: Service "TSfile Network/Multiplex [onid:0001 tsid:03ED]/ORF2St HD" PMT (version 15) updated, New CA stream, New CAID

2025-11-02 10:57:40.270 [  DEBUG]:service: TSfile Network/Multiplex [onid:0001 tsid:03ED]/ORF2St HD: Status changed to [Hardware input] [Input on service] [Demuxed packets] [Reassembled packets] [No available descrambler] [No access] 

2025-11-02 10:57:40.765 [WARNING]:subscription: 0002: service instance is bad, reason: No descrambler

2025-11-02 10:57:42.768 [  DEBUG]:service: 1: ORF2St HD si 0x7ca0d800d960 TSFile weight 0 prio 10 error 400 (No descrambler)

2025-11-02 10:57:42.768 [WARNING]:webui: Couldn't start streaming /stream/channel/e5e7f551b803728611ee0d156e5f2fc0?ticket=2f75f2bda6b7eab98daeb2e86128d6765fc8357a, No descrambler

I think that the problem is not with the change of programme PIDs, but with the change in encryption status.

Looking at dvb_psi_pmt.c, it does recognise some changes to CA parameters, and I can see some of those messages in the log. TVH seems to be recognising the change in encryption, it is just not applying those changes correctly.

Perhaps the PMT_UPDATE_CAID_DELETED flag is not being set correctly. The stream is not CHANGING encryption, it is LOSING encryption.

I'm afraid that I am probably getting close to the end of what I can achieve on my system. In Australia, our DVB-T is not encrypted and our encrypted pay TV services all have proprietary set-top-boxes. I don't have the resources, or domain knowledge, to proceed much further.

phaze75

DeltaMikeCharlie *** Here TVH sees the encryption change.
2025-11-02 10:57:40.241 [ DEBUG]:tbl-base: pmt: Service "TSfile Network/Multiplex [onid:0001 tsid:03ED]/ORF2St HD" PMT (version 15) updated, New CA stream, New CAID

2025-11-02 10:57:40.270 [ DEBUG]:service: TSfile Network/Multiplex [onid:0001 tsid:03ED]/ORF2St HD: Status changed to [Hardware input] [Input on service] [Demuxed packets] [Reassembled packets] [No available descrambler] [No access]

2025-11-02 10:57:40.765 [WARNING]:subscription: 0002: service instance is bad, reason: No descrambler

2025-11-02 10:57:42.768 [ DEBUG]:service: 1: ORF2St HD si 0x7ca0d800d960 TSFile weight 0 prio 10 error 400 (No descrambler)

I'm just trying to figure out how this "No descrambler" error can possibly relate to my recent observation:

phaze75 But what I observed is, that the ORF2St HD stream was still running in the /Status/Stream window, the bandwith values were constantly changing as usual and the error counters were not counting up. I then checked the oscam live-log and I could see, that also descrambeling of ORF2St HD was still up and running and not throwing any errors. So, I assume that whatever in the process crashes on the TVH side, crashes after receiving the descrambling keys.

If TVH is throwing any errors related to descrambling, shouldn't there be also errors in the oscam live log?

DeltaMikeCharlie

I hacked dvb_psi_pmt.c to always delete the CA PIDs and the stream continued for a little while longer than before, but eventually went blank. This time, however, the stream kept going. Stats in TVH and VLC show that data is still flowing.

I also managed to capture the PID list.

Before

After

It seems that TVH has added the new programme PIDs, but not released the old programme PIDs.

DeltaMikeCharlie

DeltaMikeCharlie It seems that TVH has added the new programme PIDs, but not released the old programme PIDs.

I added a lot of debug code today and I am now of the opinion that the 'problem' with the retained PIDs is a WebUI display problem. When I do a debug dump the PID list, I only see the current PIDs, not the old ones.

The decrypted stream that I have was helpful to this point, however, because the PMT still contains data pertaining to decryption, I still get descrambling errors. Perhaps I can hack TVH to ignore all of the decryption stuff on my test system, hopefully eliminating the descrambling errors.

Until I can get a clean descrambled stream that changes PIDs, I can not be certain where the problem is.

Sp3ncMan

Hi all,

I have debugged also and think that the problem is in TVH that there is no CAPMT update when switching from national to regional. So Descrambler locked on old PIDs but TVH is working with new PIDs. So I made 3 changes to try to correct this problem with existing TVH without patching something. I'm no software developer, just IT guy ;-)

Change 1)

Web-UI - Konfiguration - Stream - Stream Filters - CA Stream Filter:

Fixed PID 2502 for Irdeto ECM stream.

Change 2)

added:
"capmt_full": true,
"capmt_force": true,
"capmt_interval": 5,
"capmt_oscam": true,
"capmt_force_init": true

between {} in file /var/lib/tvheadend/caclient/[some string of your TVH-CA]
Purpose: tells TVH to

send only full PMT tables, no incremental tables
forces to send PMT Updates on ANY changes
sends CAPMT updates every 5s
activate oscam compatible protocoll
forces tvh to reinitialize the complete descrambler on capmt updates

Change 3)

added:
"capmt_send_full": true,
"capmt_per_service": true

between {] in file /var/lib/tvheadend/config

And these changes are WORKING in my setup from national to regional swich. Tried it again today and the switch at 18:57:29 worked like a charm with no freeze at all. Would be great if you could try and come back if it works also for you!!

My logs showed, that TVH send new CAPMT (!!!), Oscam updated, and ECM PID is also active. No change to wrong CAIDs, no ECM timeouts.

Then I tried the switch from regional to national and another bug popped up. TVH is sending a CAPMT update, but SID stays the same (13302 for ORF2K in my example). TVH is thinking its just an update not an "new service" and old descrambler is not updating PID mapping. --> no pic, no sound, freeze!

So I will try some workaround by adding:

Change 4)

added:
"capmt_clean_on_close": true

between {} in file /var/lib/tvheadend/caclient/[some string of your TVH-CA]

I will try this change tomorrow when next regional window will be active.

/Mario

phaze75

Sp3ncMan So I made 3 changes to try to correct this problem with existing TVH without patching something.

Wow, could this really just be a configuration issue? It sounds almost too good to be true! Unfortunately, I won’t be able to test your settings until Wednesday evening this week, but I’ll definitely give it a try. Thanks for sharing your results!

Sp3ncMan

phaze75

I think, in any way it's a kind of bug of TVH. ORF and Astra are doing things which are technical standard for decades. There are simple too less, crazy, people like we, who need this feature in TVH ggg :- )

The more complex Problem will be, to get some developer who is able to recreate the situation (regional, encryption, ...) and who is able to fix the bug in the code.

Capmt client/server have some settings which hopefully can conceal the bug more or less. Hopefully!! Perhaps this works for us ... don't know!

« Previous Page