[mythtv-users] Channels not showing up in the "right" place [PARTIALLY-SOLVED]

[Michael T. Dean]

On 10/20/06 12:48, Rob Kaufman wrote:

>  My wife mentioned that our local channels where missing from MythTV.
> We have DirectTV, so all channels come through satellite, but the
>channels that are also broadcast over the air (ABC, NBC, FOX, etc) are
>what she means by local channels.  I looked at DataDirect and they
>appear to be correct.  After some serious digging around I discovered
>that the problem is mythfilldatabase expects the XMLTVID to be unique
>for each channel.
>
Yes.  The xmltvid is a unique identifier that allows syncing XMLTV data 
(or XMLTV-like data, such as DataDirect data) to a channel in the MythTV 
database.  However, you can define multiple channels with the same xmltvid.

>  It is not if the station appears on more than one
>channel.
>
Because it /is/ the same channel--just different channel numbers.  See, 
also, http://www.gossamer-threads.com/lists/mythtv/dev/150626#150626 .

>  For instance my DataDirect was set up with KPBS on channel
>15 AND on channel 971 (which I don't receive).  What would happen was
>the database would get update  both database rows first to channum 15
>and then to channum 971.
>
mfdb ignores channum and, normally (see below), only adds channels whose 
xmltvid,  given by DataDirect's stationid (which is identical for 15 and 
971 on your lineup), doesn't already appear in the DB.  So, if you have 
channel 971 defined, it won't create a new 15.  If you have 15 defined, 
it won't create a new 971.

>  This can be (partially) solved by removing
>the high number channels from zap2it.
>
However, they will be reselected if you allow mfdb to update your lineup 
(i.e. with digital sources or with --remove-new-channels for analog 
sources) when there are channels on the lineup that aren't in the Myth 
database.  But, having both selected has no effect on the mythtv 
database (except as described below) and only results in a tiny amount 
of additional data in the DataDirect download (i.e. a few kB 
uncompressed for 50 duplicate channels).

>  I would like to propose a more
>complete solution would be to change the updates from being this:
>UPDATE channel SET callsign  = 'KPBS',  name   = 'KPBS',     channum
>= '15',   freqid = 15,     atsc_major_chan = 15,     atsc_minor_chan =
>0 WHERE xmltvid = '10637' AND sourceid = 1;
>
>to:
>UPDATE channel SET callsign  = 'KPBS',  name   = 'KPBS',     channum
>= '15',   freqid = 15,     atsc_major_chan = 15,     atsc_minor_chan =
>0 WHERE xmltvid = '10637' AND freqid = 15 AND sourceid = 1
>
>I would really appreciate peoples thoughts on this before I work up a patch.
>
That will break for users whose freqid is frequency in kHz (which 
shouldn't happen for anyone using a STB, but using freqid shouldn't be 
necessary, anyway).

Also, and more importantly, that query only appears in 
DataDirectProcessor::UpdateChannelsUnsafe(), which is only executed if 
the user specified --do-channel-updates.  This argument should /not/ be 
specified in the daily run of mythfilldatabase (i.e. make sure it's not 
in your (mythfilldatabase Arguments" setting).  Instead, it should only 
be specified when updating your sources.

When updating your sources, you should 1) delete any channels you don't 
want in Myth from the Myth database using the channel editor (or all of 
them since they'll be repopulated in a moment), 2) edit your lineup at 
http://labs.zap2it.com/ to show /only/ the channels you want in your 
source (i.e. the low ones in your case--deselect the high ones), 3) run 
"mythfilldatabase --do-channel-updates" (which, will add in any 
additional channels or channels you deleted).

Then, if you notice that you accidentally left 971 selected and forgot 
to select 15, use the channel editor to change the channel number from 
971 to 15.

If this doesn't work for you, please let me know, because I'm pretty 
certain it's all working correctly when the proper update procedure is 
followed.  If it doesn't work, I'll need more info to figure out what 
exactly is happening.

Thanks,
Mike