DVB Channel Scan creates large number of conflicting channels

[Argus <pthorn-mythd@…>]

Channel scanning DVB transports can create an unworkable number of "conflicting" DVB channels (MythTV 0.24-fixes branch). Multiple hundreds of conflicting DVB channels were reported when scanning up to 32 transports. Additionally, multiple non-existent MPEG channels (some conflicting, some not) were reported. The MPEG channels appear to correlate directly to the DVB channels (channel numbers are the same).

This occurs during Full Scan, Scan Existing Transports and Scan Single Transport functionality and is consistently failing across multiple scans.

Some seemingly random and inconsistent transports do succeed in creating usable DVB channel lists. Different transports fail and succeed across multiple scanning runs.

Existing channel lists were cleared prior to scanning.

While it is theoretically possible to work around this issue with manual insertion of the channels, the large number of conflicts makes this a very arduous process.

[Argus <pthorn-mythd@…>]

Myth version information

[Argus <pthorn-mythd@…>]

Patch to correct conflicts

[Argus <pthorn-mythd@…>]

See also attached patch.

This comment gets technical, but it may be important to understand why the patch should work and what was going on because this is not going to be easy to recreate or test.

What's happening here underneath is that the channel scanner is failing to process segmented SDT packets correctly. The bug is somewhat subtle.

If the scanner receives a segmented table, the first segment will trigger the bug. The code (specifically in UpdateChannelInfo?()) tried to determine if it had processed the SDT table before. In doing so, it created a default QMap entry to check if it was empty or not:

if (!currentInfo->sdts[tsid].empty()))
  continue;

The side effect: currentInfo->sdts is no longer empty as element [tsid] must be created by the sdts QMap object to call the method empty() on it.

Later in the processing, the code checks thus:

        if (sd->HasCachedAnyNIT() || sd->HasCachedAnySDTs())
        {
            transport_tune_complete &= !currentInfo->nits.empty();
            transport_tune_complete &= !currentInfo->sdts.empty();
        }

If the scanner has already processed an NIT table, then this code will generally indicate that the transport has completed tuning, even if the SDT is not complete (see above). This later leads to a partial processing of an incomplete channel list. Because the SDT entries aren't there as this is only the first segment of the SDT table, the channel listing only consists of PAT and PMT entries which are interpreted as the wayward MPEG channels.

When the last SDT segment arrives, it kicks off the above code (again), this time correctly, and a complete channel listing, including the cached SDT tables, is processed. This is appended to the earlier scan information from segment 1. This creates the conflicts, as the channel numbers between the partial segments internally conflict.

Of note, this situation is avoided when an NIT table arrives after a completed set of SDT tables, resulting in the seemingly random (and confusing) successful scans as noted in the bug report above.

There are various ways to fix this bug, but I believe the easiest is in the attached patch. i.e. changing out the test for one that doesn't modify currentInfo->sdts:

   if (currentInfo->sdts.contains(tsid))
            continue;

The patch doesn't create the troublesome default QMap entry when checking if the SDT tables already exist and the remainder of the processing completes unhindered.

This has corrected the issue for me for all cases noted in the bug (and significantly reduced frustration levels!)

Hope this helps.

[karljah@…]

Hi there,

Sorry if this is a dumb noob mistake, but when inputting the first line of the patch into terminal, I get diff: unrecognised option '--git'

I'm running Ubuntu 10.04.3 LTS.

Any solutions please?

[Argus <pthorn-mythd@…>]

First:

man patch

Then (the basics):

cd <<your git checkout directory>>/mythtv

<<download/copy the patch to this directory using 
   wget/curl or copy/paste in your favourite editor>>

patch -p1 < patch.txt

<<recompile/reinstall myth>>

(This sort of discussion is probably better suited to the myth-users@ mailing list)

[jack@…]

Has patch found its way into 0.24-fixes yet?

[dekarl@…]

I've just test channel scanning german DVB-C with/without this patch and it makes a huge difference (as does restarting mythtv-setup between scans, but thats another topic ;)

without the patch

14 Transponder gefunden:
Sender: FTA Enc Dec
ATSC        0   0   0
DVB        67   0   0
SCTE        1   0   0
MPEG       42   0   0
NTSC        0
Eindeutig: prog 110 atsc 0 atsc minor 0 channum 108
 
7 Transponder gefunden:
Sender: FTA Enc Dec
ATSC        0   0   0
DVB         0   0   0
SCTE        1   0   0
MPEG      112   0   0
NTSC        0
Eindeutig: prog 79 atsc 0 atsc minor 0 channum 79
Max atsc major count: 0
 
 
33 Transponder gefunden:
Sender: FTA Enc Dec
ATSC        0   0   0
DVB        70   0   0
SCTE        2   0   0
MPEG       60   0   0
NTSC        0
Eindeutig: prog 132 atsc 0 atsc minor 0 channum 130
Max atsc major count: 0

with the patch applied

33 Transponder gefunden:
Sender: FTA Enc Dec
ATSC        0   0   0
DVB       102   0   0
SCTE        2   0   0
MPEG       28   0   0
NTSC        0
Eindeutig: prog 132 atsc 0 atsc minor 0 channum 124
Max atsc major count: 0

# rescan
33 Transponder gefunden:
Sender: FTA Enc Dec
ATSC        0   0   0
DVB       126   0   0
SCTE        2   0   0
MPEG       45   0   0
NTSC        0
Eindeutig: prog 139 atsc 0 atsc minor 0 channum 119
Max atsc major count: 0
 
# restart
33 Transponder gefunden:
Sender: FTA Enc Dec
ATSC        0   0   0
DVB       102   0   0
SCTE        2   0   0
MPEG       28   0   0
NTSC        0
Eindeutig: prog 132 atsc 0 atsc minor 0 channum 124
Max atsc major count: 0

[Github]

Fixes #10054. Fixes handling of segmented SDT and PAT tables.

The code was attempting to verify if it had seen an SDT for a given TSID before, and it inadvertantly created an empty entry rather than just verifying it was missing.

This leads to further errors when the scanner thinks it has an SDT for a transport when it is in fact missing it.

The same logic issue was found in the PAT handling.

Based on original patch by Argus <pthorn-mythd at styx2002.no-ip.org>

Branch: master Changeset: 778d8111e8ffd61118cf36262eb0a1422a70ffd2