[mythtv-users] Anyone in UK - Don't forget to do your DVB-T retune today.

Neil Milne neil.milne at gmail.com
Fri Oct 2 18:37:36 UTC 2009

2009/9/30 Neil Bird <neil at fnxweb.com>

>  Yes, I know this would have significantly more useful before today but I
> didn't find the time.
>  I'm looking a cobbling together a script that corrects the channel
> mplexid/serviceid fields based upon what frequencies are in the dtv_multiple
> table and a fresh tzap channels.conf.
>  This is, effectively, what I've been doing by hand when the occasional
> channel moves around anyway, but I'm using today's bigger changes as the
> impetus to automate the process.
>  The main reason I don't like using Myth to re-scan is that I've normalised
> the channel names to match what I have for my Sky channels, and I suspect (I
> have asked but not had a reply) that the re-scanner will use the channel
> names (as set from the scan) to tie things together, so I presume I'd just
> get loads of *new* channels instead of fixing my existing ones.
>  I have a number of questions, then:
> - What has people's experience been with re-scanning?  Do you keep the
> off-air channel names as they were originally set (ugly all-caps and all)?
Yes - I normally just keep the channel names all-caps, too lazy to change.

I did a full rescan of existing transports (using the Crystal Palace
transmitter here) and it all seemed to work reasonably well for a change. I
did get some duplication of channel number where the old channel was left
behind and the new one had been created, so I used mythweb to remove the old
outdated channels.

I was left feeling doubtful that my recording rules would still work
however, since I often specify 'record on this channel' and I noticed that
mythweb had stopped reporting the channel name for the recording rules which
used channel 5. I suspect this is because they are joined using the 'chanid'
which seems to be assigned by mythtv during the scan process, rather than by
callsign or channel number.

Does anyone know if the backend is clever enough to reassociate rules where
the chanid has vanished but the callsign is still around? I did see some
denormalization in the record table so it may have that capability, but I
didn't trust it so manually updated my database to sync up the new

I suspect a script using the tzap output to directly update the relevant
fields would be better from this perspective, because it would preserve the
chanid values.

I just wish the rescan functionality built into mythtv-setup would do
something like this... Unfortunately my area of expertise is Java, not C++
so most of the mythtv code is pretty unintelligible to my untutored eyes :-)


Neil Milne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20091002/0b3cf6f2/attachment.htm>

More information about the mythtv-users mailing list