[mythtv] Why MythTV didn't handle the UK Freeview lineup change

[John Barberio]

Since none of the developers seemed interested in working out why  
MythTV couldn't cope with the lineup change moving 'Virgin 1' to a new  
mux, and a 'new' channel created for 'Virgin +1'. I've attempted to  
work out what the problem might be with black-box reverse engineering  
of how MythTV appears to have reacted to the lineup change.  
Developers, feel free to dispute this with your knowledge of how  
MythTV works.

MythTV, unlike most other DVB systems, does not store video and audio  
pids in its channel data. It only stores the NIT channel id number,  
and recovers the video and audio pid from the current broadcast NIT  
each time the channel is accessed. However, it *does* store the  
channel's name and the LCN for that channel.

Now, the problem is this... This design makes the assumption that  
channel id numbers are UUIDs and will never be reused for a different  
channel.

This isn't true. What happened with the 'Virgin 1' line-up change was  
that 'Virgin +1' used the same channel id number as the old 'Virgin  
1'. As far as mythtv was concerned, the channel it knew as 'Virgin 1'  
was still there, since it sees the channel id number, and tunes to  
that not knowing this is now the channel id for 'Virgin +1'. Oddly,  
the program information scraper doesn't seem to make this mistake, and  
manages to pick up the different program information for the new  
'Virgin 1'. This leads to the apparent 'hour out of step' bug, since  
the program information for the real 'Virgin 1' is showing, but  
'Virgin +1' is what gets tuned to. (Alternatively, it might be the  
other way around. With the channel tuning doing it right, and program  
information doing it wrong. Either way, one of them 'regenerates' the  
wrong channel information.)

Now, combine this with another characteristic of MythTV, that database  
deletes aren't active till a mythfilldatabase run. Then you have the  
situation where the end user *can't delete* 'Virgin 1' and rescan,  
because the deletion isn't flushed before they do a rescan, and the  
channel scanner sees the old channel id, and makes the same mistake  
again.

So, what's the solution... Short term... *Synchronise database deletes  
in channel data before doing a rescan*! This is perhaps a one line  
addition to code somewhere appropriate, and adds only a short pause  
for that operation to the rescan process. This will now make the  
troubleshooting step of 'delete the channel and rescan' actually work.

Longer term, be careful with avoiding assuming Channel ID Numbers are  
unique against all situations, because they are only guaranteed to be  
unique at any given time of transmission. Look for where to put in  
checks to see that what MythTV thinks a channel is, is correct. Work  
out what to do when the LCN and channel name for a channel ID number  
change.

   - John