Bug #5767

TVH PID filtering and Continuity Counter errors

Added by Zbyněk Šrubař almost 4 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Found in version:
Affected Versions:


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


TVH_trace.txt (46.5 KB) TVH_trace.txt Zbyněk Šrubař, 2019-11-05 00:16
log.txt (3.18 KB) log.txt Petr Andrysek, 2019-11-08 18:17



Updated by Luis Alves almost 4 years ago

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ř almost 4 years ago

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 Luis Alves almost 4 years ago

Are the channels encrypted?


Updated by Jaroslav Kysela almost 4 years ago

You can do a simple test - use the mux URL (the play icon in the mux grid) and add pids=2410 http argument like:


Then use any tool for analysis, like (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 almost 4 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 almost 4 years ago

BTW: Which mux do you test (name or channels?). I can test it here (South Bohemia), too...


Updated by Zbyněk Šrubař almost 4 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ř almost 4 years ago

I used 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 4 years ago

Same for me, running on rpi2(raspbian) with Xbox dvb-t2 tuners, takes some time to actually open the stream.


Updated by Flole Systems over 2 years ago

  • Status changed from New to Invalid

Also available in: Atom PDF