<br><br><div class="gmail_quote">2009/9/30 Neil Bird <span dir="ltr"><<a href="mailto:neil@fnxweb.com">neil@fnxweb.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Yes, I know this would have significantly more useful before today but I didn't find the time.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
I have a number of questions, then:<br>
<br>
- 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)?<br>
<br></blockquote><div><br>Yes - I normally just keep the channel names all-caps, too lazy to change.<br><br>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.<br>
<br>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.<br>
<br>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 chanids...<br>
<br>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.<br><br>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 :-)<br>
<br>Cheers<br>Neil<br><br></div></div>-- <br>Neil Milne<br>