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

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.

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?

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!

phaze75

Sp3ncMan
Today, I finally managed to implement all suggested changes 1-4. The national/regional switch worked with a small glitch in the stream. Unfortunately, I am not sure if this really due to the changes made today, as the national/regional switch seemed to work also during the last days without implementing the changes 1-4.

So, I hoped the regional/national switch would now work or at lease be improved, as this switch always crashes the stream. Unfortunately, there was no improvement - the stream went dark as always.

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!

phaze75

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

Does it work for you?

Sp3ncMan

Hi, the switch from national to regional works, from regional to national not. after I watched "Kärnten heute" once, the national stream doesn't work at all. only tvheadend restart helps. very strange.

but I think the variables above are without function in newest versions. they have patched it out. only configuration which is still configured is the ca stream filter, but as you mentioned, I think in the actual versions they have made some changes done which partially helped us. hopefully the change from regional to national will also work anytime in the future ..

Actual version is 4.3-2514_g2169e1235.

phaze75

Sp3ncMan after I watched "Kärnten heute" once, the national stream doesn't work at all. only tvheadend restart helps. very strange.

Same here. But this was and is the very reason I started this thread.

Sp3ncMan but I think the variables above are without function in newest versions. they have patched it out. only configuration which is still configured is the ca stream filter, but as you mentioned, I think in the actual versions they have made some changes done which partially helped us.

@DeltaMikeCharlie What is your expert opinion on the changes 1-4? Are these variables still available/relevant or have they been patched out?

@DeltaMikeCharlie I have sent you a PM via LibreELEC forum. Could you please check your inbox there?

Sp3ncMan

in the meantime version 4.3-2518_g7f9710c13noble became online. will try that.

phaze75

Sp3ncMan in the meantime version 4.3-2518g7f9710c13noble became online. will try that.

I removed changes 1-4 for now and also installed version 4.3-2518g7f9710c13noble. Let's see.

DeltaMikeCharlie

phaze75 What is your expert opinion on the changes 1-4? Are these variables still available/relevant or have they been patched out?

I'm sorry but I am not an expert. We don't use encrypted FTA services in Australia and I don't know that the result of these proposed changes will be. I have run out of ideas.

phaze75 I have sent you a PM via LibreELEC forum. Could you please check your inbox there?

Thank you. I have replied.

phaze75

DeltaMikeCharlie I have run out of ideas.

Thank you for your efforts put into this issue so far.

DeltaMikeCharlie

phaze75 Thank you for your efforts put into this issue so far.

You are welcome.

The final test that I wanted to achieve on this issue was to see how TVH handles the change in PIDs without the complication introduced by encryption.

I hacked TVH to ignore the CA tags embedded in the PMT of my unencrypted sample stream and then started playback using both VLC and Kodi individually.

When the PID transition occurred, VLC (http) glitched slightly and played for a few seconds before freezing permanently. Playback on Kodi (htsp) froze for at least 2-3 minutes, but then resumed in roughly the right place.

I got lots of error messages about DTS discontinuity, etc.

2025-11-11 14:41:39.890 [WARNING] mpegts: too much queued input data (over 50MB) for TSFile, discarding new
2025-11-11 14:41:40.106 [WARNING] TS: TSfile Network/Multiplex [onid:0001 tsid:03ED]/ORF2St HD: H264 @ #3010 Continuity counter error (total 1)

2025-11-11 14:41:40.111 [WARNING] parser: TSfile Network/Multiplex [onid:0001 tsid:03ED]/ORF2St HD: H264 @ #3010: DTS and PCR diff is very big (685745)

Just before the Kodi unfreeze, the log was bombarded with dozens of DTS discontinuity errors before settling down and then Kodi proceeding without error.

2025-11-11 15:02:20.796 [WARNING] tsfix: transport stream H264, DTS discontinuity. DTS = 138378623, last = 137728823
2025-11-11 15:02:20.796 [WARNING] tsfix: transport stream H264, DTS discontinuity. DTS = 138648623, last = 138378623

At the second transition, it seems like Kodi jumped back in time to just after the first transition. The stream played for several minutes before my test system spontaneously rebooted.

I think that I have 2 findings:

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.

phaze75

DeltaMikeCharlie 1) Streaming results seem to depend on the client and/or the protocol in use.

I will try to verify that with VLC and Kodi on my side using the live stream and the live decryption.

BTW: Only today I received an answer from ORF concerning my request from end of October for a detailed technical description of what is happening. Their answer was very unspecific and for more detailed information I would need to give them the receiver brand and and model. So I guess this ends here.

phaze75

DeltaMikeCharlie 1) Streaming results seem to depend on the client and/or the protocol in use.

I can confirm your finding #1. Today, I used two Kodi clients (Win+CoreELEC) via RTSP and one VLC client via HTTP to access the same ORF2St HD stream. All three clients handled the switch from national to regional with the usual glitches, but surprisingly, VLC even "survived" the switch back from regional to national, while both Kodi clients went black.

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.

Maybe the problem isn’t tied to a specific client but to the protocol being used. Is there a way to get Kodi to play a stream over HTTP?

Additionally, I can confirm that the PID list only grows by adding new PIDs and isn’t cleaned up when PIDs are no longer in use. Since VLC continues to play using the same PID list without problems, I doubt this is a critical issue.

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?

Sp3ncMan

Hi DMC,
in my opinion its definitive a TVH topic, not Client dependent. Because? Because the result is the same with every client:

Channels, which have been viewed at time of switching, are getting DARK - until you restart TVH. No matter what client has been used for viewing.

/Mario

DaveH

Sp3ncMan in my opinion its definitive a TVH topic, not Client dependent. Because? Because the result is the same with every client

How do you reconcile your opinion with DMC's description of different results using VLC and Kodi?

Sp3ncMan

Very interesting what I tried today: recorded the "dark" orf2khd channel, copied TS file to windows pc and played it with VLC, it works. So raw data, from satellite to backend works. There seems to be a problem with backend to client ... somewhere!!!???

EDIT: also playing "dark" channel-record with Kodi works ...

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

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.

phaze75

phaze75
Could the profile be causing the issue, since Kodi uses "htsp" and VLC uses "pass"?

Sp3ncMan

phaze75

we both are on the same direction ;-), try at the moment with different profiles, but nothing works yet with kodi ... seems that kodi client is htsp only.

EDIT: TVH Web Player has obviously the same problems than kodi. Channels stay dark, btw ...

« Previous Page Next Page »