Opened 10 years ago

Closed 9 years ago

#8078 closed defect (fixed)

Duplicate channel numbers incorreclty reported in Channel Scan

Reported by: Bob Shanteau <rmshant@…> Owned by: robertm
Priority: minor Milestone: 0.24
Component: MythTV - Channel Scanner Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Enter Channel Editor->Channel Scan, and scan over multiple transports. Enter channel numbers manually. On second and following transports, entering a unique channel number results in a message saying that the channel number is not unique. Entering the same unique channel number a second time is OK.

System: MythDora? 12.23 Beta, all Fedora 12 updates, AMD X86_64, nVidia PCIe 7200, and Dvico Dual Express or HDHomerun NTSC.

Change History (5)

comment:1 Changed 10 years ago by robertm

Milestone: 0.23unknown

comment:2 Changed 9 years ago by robertm

Component: MythTV - GeneralMythTV - Channel Scanner
Owner: changed from Isaac Richards to danielk

comment:3 Changed 9 years ago by robertm

Status: newassigned

comment:4 Changed 9 years ago by robertm

Milestone: unknown0.24
Owner: changed from danielk to robertm
Version: unknownTrunk Head

This issue is almost definitely the last remaining issue I am tracking down for #7838, should hopefully have a fix in the next day or two.

comment:5 Changed 9 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.