Opened 14 years ago

Closed 14 years ago

#7838 closed defect (fixed)

Channel scanner reports many duplicate/conflicting channels on a fresh database, presents incomprehensible options

Reported by: cpg <cpg@…> Owned by: robertm
Priority: blocker Milestone: 0.24
Component: MythTV - Channel Scanner Version: Master Head
Severity: medium Keywords: channel scanner duplicates
Cc: Ticket locked: no

Description (last modified by robertm)

Requested the filer provide these logs. mythtv-setup channel scan with channel scanner verbose options. On a fresh DB and video source, QAM scan reports numerous dupes and various types of channels, presenting options that have no obvious right answer.

Attachments (2)

mythtv-setup.log.bz2 (122.6 KB) - added by robertm 14 years ago.
channel scanner logs
mythtv-setup.log.2.bz2 (123.1 KB) - added by cpg <cpg@…> 14 years ago.
after those few, we got a bunch more dups. here is the full log

Download all attachments as: .zip

Change History (12)

comment:1 Changed 14 years ago by robertm

Component: MythTV - Mythtv-setupMythTV - Channel Scanner
Description: modified (diff)
Keywords: channel scanner duplicates added
Owner: changed from Isaac Richards to danielk
Priority: minormajor
Status: newassigned

Changed 14 years ago by robertm

Attachment: mythtv-setup.log.bz2 added

channel scanner logs

comment:2 Changed 14 years ago by robertm

Summary: mythtv-setup barfs with a bunch of duplicate channelsChannel scanner reports many duplicate/conflicting channels on a fresh database, presents incomprehensible options

Changed 14 years ago by cpg <cpg@…>

Attachment: mythtv-setup.log.2.bz2 added

after those few, we got a bunch more dups. here is the full log

comment:3 Changed 14 years ago by otto at kolsi dot fi

See also #7284

comment:4 Changed 14 years ago by wjhns176@…

I just got a new HD tuner and am hitting this problem, and it's nasty. There are way too many conflicts to figure out how to deal with and what's presented to the screen is of no help to the user unfortunately. After reading archives, it seems that it might just be the sub-channels that conflict but I'm taking that on word of mouth from email archives. If true, 114-1 would be fine until 115-1 comes along and it's marked as a conflict (but you don't have "114" or "115" or even "-1" on the screen to help you make an intelligent choice).

comment:5 Changed 14 years ago by robertm

Milestone: unknown0.24
Priority: majorblocker
Version: unknownTrunk Head

I've never managed to get a working scan with the new scanner due to this issue. Upping priority and setting milestone to .24. Any fresh scan on my cable system presents dialogs for hundreds of conflicting channels of types that my system can't possibly support, and provides the user with no usable feedback about what they are confirming/ignoring. The only thing the user sees is a giant UUID, how are they to know whether to add/ignore/whatever it?

comment:6 Changed 14 years ago by danielk

Owner: changed from danielk to robertm

comment:7 Changed 14 years ago by robertm

(In [26154]) Channel Scanner: Add a SimpleFormatChannel? Function to format channel information in a more conventional way to present it to the user-- will output the full debug data to the log, but the user needs to be accustomed to the information he is deciding based upon, so present the major and minor channel, callsign, and channum, or in the case of DVB, the serviceID/channum. All the info will still be there for debugging, will just make it easier to make informed decisions without all the information overload. Refs #7838.

comment:8 Changed 14 years ago by robertm

ATSC appears never to be found in conflict, but MPEG are sometimes and SCTE/OpenCable always appear to be-- seems to be that some part if the data passed to IsConflicting?() is bad, and thus falsely identifies the channel as a conflicting channel. Just can't figure out what yet.

comment:9 Changed 14 years ago by robertm

(In [26168]) Channel Scanner: Multiple fixups for the channel scanner. First, fix multiple wrong arguments being passed to IsConflicting?()-- the serviceid was being passed in as the sourceid for some reason. Also, construct ClearQAM channels are they used to be-- freqid-service_id (ie 105-2). For some reason, some of the MPEG and SCTE channels are *still* being considered conflicting in spite of the fact that they appear nowhere in the video source, but then the suggested channum (which is identical to the original, conflicting one) is inserted just fine.

This leaves the channel scanner in a state where it is at least possible to just scan, Insert All, and then hit Suggest->OK until the "conflicting" channels are all inserted, and gives a proper, working lineup. The only thing left to do is figure out why these channels are still being considered Conflicting.

Refs #7838.

comment:10 Changed 14 years ago by robertm

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.