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

[Richard Morton]

Hi,

This is the first I have seen of this issue and I notice that I do not have
V1+1 and only have V1 on channel20.

How do I resolve this issue, I can't find anything on the wiki...

How stupid am I?

lol

I have posted this from dev into users, as my request is a user support
issue not a development issue

thanks for any help

R

2009/7/25 Stuart Auchterlonie <stuarta at squashedfrog.net>

> 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
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090725/54a8963b/attachment.htm>