Opened 13 years ago

Closed 12 years ago

#7284 closed defect (Fixed)

DVB scanning founds conflicting channels with certain card

Reported by: otto at kolsi dot fi Owned by: danielk
Priority: minor Milestone: unknown
Component: MythTV - Channel Scanner Version: head
Severity: medium Keywords:
Cc: Stuart Auchterlonie Ticket locked: no


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

Attachments (1)

scan-logs.tar.gz (33.6 KB) - added by otto at kolsi dot fi 13 years ago.

Download all attachments as: .zip

Change History (7)

Changed 13 years ago by otto at kolsi dot fi

Attachment: scan-logs.tar.gz added

comment:1 Changed 13 years ago by otto at kolsi dot fi

This is more or less same issue as in #7838

comment:2 Changed 12 years ago by robertm

Status: newassigned

comment:3 Changed 12 years ago by 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).

comment:4 Changed 12 years ago by robertm

Status: assignedinfoneeded


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?

comment:5 Changed 12 years ago by Stuart Auchterlonie

Cc: Stuart Auchterlonie added

comment:6 Changed 12 years ago by robertm

Resolution: Fixed
Status: infoneededclosed

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

Note: See TracTickets for help on using tickets.