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

[Stuart Auchterlonie]

John Barberio wrote:
> 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.
> 

We are interested. In fact we are busy trying to finish off the rewrite
of the channel scanner for the 0.22 release. We've been having a think
about what you described in a effort to work out what went wrong.

> 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.
> 

The video and audio pids aren't guaranteed to be the same all the time.
Granted a lot of broadcasters don't change them to keep things simple.

What is guaranteed to be unique is the ServiceID which is found in the
PAT. This only changes when they go and rearrange the channels.

However, as far as i can tell they cheated a bit when they "moved"
virgin1. What happened was they aquired a 24hr slot on another mux
and setup virgin1 there, and their existing 12hr virgin1 slot was
renamed to virgin1+1


> 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.
> 

There are 2 distinct "channel numbers". The LCN (logical channel number)
which is what puts BBC 1 = 1, BBC 2 = 2 etc etc, and the channel id
assigned by myth which is based on a combination of the sourceid and the
actual channel number. Yes, MythTV uses this to uniquely identify that
channel, however that isn't what it uses when making scheduling
decisions, that uses the callsign. This allows us to select a channel
to record from multiple different sources, for example, if you had both
dvb-t and dvb-s (for freesat), channels like BBC 1 can be found on
multiple inputs and considered as valid candidate for a recording.

Once it has picked a channel number to record, then the tuning info
is retrieved from the database.

Chanid gives us serviceid & mplexid
mplexid gives us freq, code rates and all the other details for the mux.

We then tune to the mux based on the data we found from looking up the
mplexid. Then we use the PAT to find the PID for the PMT, from the PMT
we find the PIDs for the video and audio streams and then off we go
on our merry way.

So channelid's have to be unique so that myth can record what you want.
The underlying problem, seems to be more a case of the data wasn't
correctly updated when a scan was done, rather than the uniqueness of
the chanid.


> 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.)

Since you are talking about mythfilldatabase i'm making the assumption
that you use RT as a program listing source via xmltv. This would also
mean you have setup xmltvid's on your channels, and since setting them
up is a pain, you've probably done a scan for channels without deleting
the old ones first.

Personally i use, EIT so i tend to delete all my channels and rescan.
What i did notice is that they did broadcast incorrect data for the
changeover period, but they quickly sorted that out.

Assuming you did an update scan, here's my best guess of what happened
with the channel data.

Myth probably didn't update the channel info correctly, leading to it
still being labelled as Virgin1, when they had started broadcasting
virgin1+1 on that slot. If the xmltv id hadn't been updated then it
would still be setup for the virgin1 xmltv data, and MFDB would duly
put the data for virgin 1 in there. That's my best guess for what
happened there.

> 
> 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.
> 

I'm not sure what you mean here? In the channel scanner if I tell it to
delete the channels, that's what it does, there and then.

> 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.
> 

Myth generates its own unique chanid as described above.
The fault seems to be that updating channels hasn't worked
as well as it could.

Hopefully that explains some things...


Stuart