Bug #5767
TVH PID filtering and Continuity Counter errors
0%
Description
Recently public TV DVB-T2 mux in Czech Republic changed something and all users of X-box tuners on TVH started to see Continutity Counter errors. The mux most probably introduced new channels (programs), which are sharing the same video/sounds PIDs from other channels and only in specific times offers their own video/sound. Please note that other DVB-T2 muxes still play fine without any errors. The issue is reported only for X-box tuner.
X-box tuner doesn't provide PID filtering by HW. At least this option is not offered by the driver. Other DVB-T2 tuners usually have such possibility (I believe). So far this problem is reported only for X-box tuner and not for other DVB-T2 tuners, so I think this might be the difference, which is causing different behavior.
In case I stream the complete mux to Kodi/VLC, no error is happening.
2019-11-04 21:41:37.994 mpegts: 514MHz in DVB-T CZ - open PID fullmux subscription [0003/0xb5602e28]
In case I stream the channel, PID filtering is activated and CC errors start to appear.
2019-11-04 20:44:34.628 mpegts: 514MHz in DVB-T CZ - open PID 096A (2410) [8/0x36e0958]
Open PID in mpegts is not followed by linuxdvb open PID call as HW PID filtering is not supported. Hence it means that there could be a bug in TVheadend part where software PID filtering is implemented and special PMT setup is received.
I am attaching TVH trace (mpegts and linuxdvb enabled).
Files
History
Updated by Luis Alves about 5 years ago
Updated by Usually PID filtering is handled by the linux dvb subsystem and not by tvheadend.
This way user apps (like tvheadend) don't need to know if a card supports hw filters or not, it simply tells the kernel which pids it wants (demux job).
Can you give more details of the machine running tvheadend (cpu/linux/kernel)?
Updated by Zbyněk Šrubař about 5 years ago
Updated by It is running on RPI4 on LibreELEC 9.2 Beta 2 (kernel 4.19.66).
I will investigate more on linuxdvb PID filtering then.
Updated by Jaroslav Kysela about 5 years ago
Updated by You can do a simple test - use the mux URL (the play icon in the mux grid) and add pids=2410 http argument like:
http://localhost:9981/play/stream/mux/319bdd7712eef18d2c77d87f9e2fb651?pids=2410
Then use any tool for analysis, like https://github.com/tvheadend/tvheadend/blob/master/support/pid-count.py (which detects PIDs and CC errors in the input stream). If no CC errors are visible, then there is probably something wrong with the packet processing in tvh. Otherwise, it seems like a driver / linuxdvb kernel subsystem issue.
Updated by Jaroslav Kysela about 5 years ago
Luis Alves wrote:
Are the channels encrypted?
No... We don't have protected terresterial broadcasting here to this date.
Updated by Jaroslav Kysela about 5 years ago
BTW: Which mux do you test (name or channels?). I can test it here (South Bohemia), too...
Updated by Zbyněk Šrubař about 5 years ago
The problem is with ČT mux (Přechodová síť 11) since ČT1 SM and ČT1 JM channels appeared.
Updated by Zbyněk Šrubař about 5 years ago
I used pid-count.py and analyzed the situation. CC errors are happening only at the beginning of the stream. This is valid for both full mux and single channel and for both live streaming and recording. Just Kodi can recover better in case of full mux errors than for single channel. So I guess this is not TVheadend issue after all.
Updated by Petr Andrysek almost 5 years ago
Updated by Same for me, running on rpi2(raspbian) with Xbox dvb-t2 tuners, takes some time to actually open the stream.
Updated by