DVB scanning founds conflicting channels with certain card

[otto at kolsi dot fi]

I have couple of different DVB-T cards and with one of them channel scan in current trunk works quite fine. With other card (Technisat AirStar?) scanner finds conflicting channels and also MPEG channels in addition to DVB channels.

I've attached gzip package which contains two logs from scanning with two different cards using Existing transports scan, Only Free and Test Decryptability on -options. Logs are with "-v channel,channelscan,extra,siparser". Package also contains dumps from the channelscan* tables.

When scanning works with the other card, there are 17 new channels found.

Following happens in the UI with the problematic card:

13 new non-conflicting DVB channels found -> insert all -> 
1 new non-conflicting MPEG channels found -> insert all -> 
4 new conflicting DVB channels -> Ignore all -> 
16 new conflicting MPEG channels -> Ignore all

[otto at kolsi dot fi]

This is more or less same issue as in #7838

[robertm]

(In [26177]) Channel Scanner: Fix for QAM/SCTE/OpenCable scanning. A full scan of Cable in the US/Canada should now produce expected channel numbering on a clean database without conflicts.

Previously, the subchannel was being used as the uniqueness identifier. So by definition, 53-1 and 54-1 and 55-1 were all in conflict, as the subchannel was all the info it had to compare.

The fix is twofold: First, switch to using channum as the "uniqueness" identifier for MPEG, SCTE, and OpenCable? channels. Unfortunately, these channels weren't being assigned a channum in the channel scanner itself, so when one of these types is present, generate a channum based on frequency identifier (what most US folks consider "physical" channel) and serviceid (what most of us consider "subchannel). This basically produces channels that are consistent with how every television in the relevant markets works, and should not hurt the scanning/channel naming conventions of any other locale at the same time. Since MPEG channels are the lowest common denominator and mostly only present on engineering/testing/non-full-fledged channels elsewhere, this channel naming scheme appears safe.

Fixes #7838. Almost certainly fixes #8078 (that, or one of the other fixes from last night should have). Refs #7284 (needs a retest after the IsConflicting? fixes last night).

[robertm]

Otto,

It may not be 100% fixed as there may well be multiple issues at play here, but there were several fixes made to the channel scanner/importer that will affect how duplicates are decided, and how channel numbers are assigned to MPEG channels. It's quite possible that one card/driver will scan better than the other, so that's not something we can easily do anything about, but I would like to see how this affects the spurious reports of duplicates. Can you update to latest trunk and attempt some scans?

[robertm]

Considering this fixed as there has been no response and the channel scanner changes I made seem relevant.