Project

General

Profile

Bug #5767

TVH PID filtering and Continuity Counter errors

Added by Zbyněk Šrubař 13 days ago. Updated 10 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
DVB
Target version:
-
Start date:
2019-11-05
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-1850
Affected Versions:

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

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

History

#1

Updated by Luis Alves 13 days 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)?

#2

Updated by Zbyněk Šrubař 13 days 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.

#3

Updated by Luis Alves 13 days ago

Are the channels encrypted?

#4

Updated by Jaroslav Kysela 13 days 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:

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.

#5

Updated by Jaroslav Kysela 13 days ago

Luis Alves wrote:

Are the channels encrypted?

No... We don't have protected terresterial broadcasting here to this date.

#6

Updated by Jaroslav Kysela 13 days ago

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

#7

Updated by Zbyněk Šrubař 13 days ago

The problem is with ČT mux (Přechodová síť 11) since ČT1 SM and ČT1 JM channels appeared.

#8

Updated by Zbyněk Šrubař 13 days 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.

#9

Updated by Petr Andrysek 10 days ago

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

Also available in: Atom PDF