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: | 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 )
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)
Change History (12)
comment:1 Changed 14 years ago by
Component: | MythTV - Mythtv-setup → MythTV - Channel Scanner |
---|---|
Description: | modified (diff) |
Keywords: | channel scanner duplicates added |
Owner: | changed from Isaac Richards to danielk |
Priority: | minor → major |
Status: | new → assigned |
Changed 14 years ago by
Attachment: | mythtv-setup.log.bz2 added |
---|
comment:2 Changed 14 years ago by
Summary: | mythtv-setup barfs with a bunch of duplicate channels → Channel scanner reports many duplicate/conflicting channels on a fresh database, presents incomprehensible options |
---|
Changed 14 years ago by
Attachment: | mythtv-setup.log.2.bz2 added |
---|
after those few, we got a bunch more dups. here is the full log
comment:4 Changed 14 years ago by
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
Milestone: | unknown → 0.24 |
---|---|
Priority: | major → blocker |
Version: | unknown → Trunk 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
Owner: | changed from danielk to robertm |
---|
comment:7 Changed 14 years ago by
(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
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
(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
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(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).
channel scanner logs