[mythtv-users] Mythfilldatabase is screwing up my channels (UK)

[Mike Perkins]

Mike McKay wrote:
> I receive DVB-T ("Freeview") in the UK using mythTV 0.20.2 running on
> Ubuntu 7.04.  I have used various versions of mythTV for about 18 months
> and normally receive program data from the Radio Times site using
> mythfilldatabase which, in turn, uses tv_grab_uk_rt.
> 
> I recently added a Hauppauge Nova-T 500 to my existing Hauppauge Nova-T
> to give me a total of three tuners and, at the same time, had my antenna
> re-oriented to a different transmitter.
> 
> To "retune" my channels I used mythTV_setup, deleted all channels and
> transports, entered the transport details for the new transmitter and
> then did a "full scan of existing transports".  (I did it this way after
> multiple problems with the simpler, more automated "full scan".)  
> 
> I then ran mythfilldatabase which did not give the desired results: it
> added a completely new set of channels which could not be tuned/received.
> 
> Looking at the database channel table, those channels which were derived
> from the transport scan had the following entries in their columns:
>     channum:  correct numerical value
>     callsign: name as below, truncated (not, I think, the callsign)
>     name:     text name
>     sourceid: 1
> 
> Those channels derived from mythfilldatabase had the following entries:
>     channum:  2nd <displayname> in xmltv entry from ~/.xmltv/channels-list
>     callsign: five-digit caps+numeric value (I think this is the callsign)
>     name:     1st <displayname> in xmltv entry from ~/.xmltv/channels-list
>     sourceid: 1
> 
> My initial conclusions are:
> 1.  The mythfilldatabase channels cannot be tuned because they have an
> alphanumeric value in the channum column.
> 2.  The callsign column for the mythfilldatabase channels is a credible
> callsign but that from the transport scan channels is not.
> 3.  From what I see in the channel table I cannot see how mythTV can
> perform an unambiguous correlation between those channels derived from
> the transport scan and already in the table, and the channel information
> it receives from the Radio Times web site.
> 
> I've now spent considerable time on this but am completely stuck.  As a
> work-around I'm now using the EIT programme data but it's not as good as
> the Radio Times.
> 
> Can anyone shed any light on this ?  Even if you don't know what's
> causing the screw-up, it would be useful to know what the channel table
> is supposed to contain when everything is working correctly and I am
> very interested to know how mythfilldatabase is supposed to work out
> what pre-existing channel corresponds to channel program data obtained
> from the RT website.
> 
We all have this problem in the UK, and it is a right pain. We have each 
individually worked out techniques for getting round the problem - mine involves 
much hand editing.

You have 3 identifiers for each channel - the channel name, which is received 
over the air, the channel code which the Radio Times uses, which is a number, 
and the xmltvid which is what the grabber uses. None of these match. Not to 
mention, some of this information is kept in the database, but the grabber uses 
a text file which Myth does *not* keep updated when you edit the database. And 
you can have different versions of <sourcename>.xmltv depending on which userid 
you ran mythtvsetup under; which userid mythfilldatabase runs under; and which 
userid the frontend runs under.

Nick Morrot, a UK Myth user, who in addition to contributing here, is on the 
xmltv mailing list, has a mechanism in the pipeline (probably some kind of 
script) which should take care of the above issues. We keenly await it.

Mike Perkins