Hi,<br><br>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.<br><br>How do I resolve this issue, I can't find anything on the wiki...<br><br>How stupid am I?<br>
<br>
lol<br><br>I have posted this from dev into users, as my request is a user support issue not a development issue<br><br>thanks for any help<br><br>R<br><br><div class="gmail_quote">2009/7/25 Stuart Auchterlonie <span dir="ltr"><<a href="mailto:stuarta@squashedfrog.net">stuarta@squashedfrog.net</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;"><div class="im">John Barberio wrote:<br>
> Since none of the developers seemed interested in working out why MythTV<br>
> couldn't cope with the lineup change moving 'Virgin 1' to a new mux, and<br>
> a 'new' channel created for 'Virgin +1'. I've attempted to work out what<br>
> the problem might be with black-box reverse engineering of how MythTV<br>
> appears to have reacted to the lineup change. Developers, feel free to<br>
> dispute this with your knowledge of how MythTV works.<br>
><br>
<br>
</div>We are interested. In fact we are busy trying to finish off the rewrite<br>
of the channel scanner for the 0.22 release. We've been having a think<br>
about what you described in a effort to work out what went wrong.<br>
<div class="im"><br>
> MythTV, unlike most other DVB systems, does not store video and audio<br>
> pids in its channel data. It only stores the NIT channel id number, and<br>
> recovers the video and audio pid from the current broadcast NIT each<br>
> time the channel is accessed. However, it *does* store the channel's<br>
> name and the LCN for that channel.<br>
><br>
<br>
</div>The video and audio pids aren't guaranteed to be the same all the time.<br>
Granted a lot of broadcasters don't change them to keep things simple.<br>
<br>
What is guaranteed to be unique is the ServiceID which is found in the<br>
PAT. This only changes when they go and rearrange the channels.<br>
<br>
However, as far as i can tell they cheated a bit when they "moved"<br>
virgin1. What happened was they aquired a 24hr slot on another mux<br>
and setup virgin1 there, and their existing 12hr virgin1 slot was<br>
renamed to virgin1+1<br>
<div class="im"><br>
<br>
> Now, the problem is this... This design makes the assumption that<br>
> channel id numbers are UUIDs and will never be reused for a different<br>
> channel.<br>
><br>
<br>
</div>There are 2 distinct "channel numbers". The LCN (logical channel number)<br>
which is what puts BBC 1 = 1, BBC 2 = 2 etc etc, and the channel id<br>
assigned by myth which is based on a combination of the sourceid and the<br>
actual channel number. Yes, MythTV uses this to uniquely identify that<br>
channel, however that isn't what it uses when making scheduling<br>
decisions, that uses the callsign. This allows us to select a channel<br>
to record from multiple different sources, for example, if you had both<br>
dvb-t and dvb-s (for freesat), channels like BBC 1 can be found on<br>
multiple inputs and considered as valid candidate for a recording.<br>
<br>
Once it has picked a channel number to record, then the tuning info<br>
is retrieved from the database.<br>
<br>
Chanid gives us serviceid & mplexid<br>
mplexid gives us freq, code rates and all the other details for the mux.<br>
<br>
We then tune to the mux based on the data we found from looking up the<br>
mplexid. Then we use the PAT to find the PID for the PMT, from the PMT<br>
we find the PIDs for the video and audio streams and then off we go<br>
on our merry way.<br>
<br>
So channelid's have to be unique so that myth can record what you want.<br>
The underlying problem, seems to be more a case of the data wasn't<br>
correctly updated when a scan was done, rather than the uniqueness of<br>
the chanid.<br>
<div class="im"><br>
<br>
> This isn't true. What happened with the 'Virgin 1' line-up change was<br>
> that 'Virgin +1' used the same channel id number as the old 'Virgin 1'.<br>
> As far as mythtv was concerned, the channel it knew as 'Virgin 1' was<br>
> still there, since it sees the channel id number, and tunes to that not<br>
> knowing this is now the channel id for 'Virgin +1'. Oddly, the program<br>
> information scraper doesn't seem to make this mistake, and manages to<br>
> pick up the different program information for the new 'Virgin 1'. This<br>
> leads to the apparent 'hour out of step' bug, since the program<br>
> information for the real 'Virgin 1' is showing, but 'Virgin +1' is what<br>
> gets tuned to. (Alternatively, it might be the other way around. With<br>
> the channel tuning doing it right, and program information doing it<br>
> wrong. Either way, one of them 'regenerates' the wrong channel<br>
> information.)<br>
<br>
</div>Since you are talking about mythfilldatabase i'm making the assumption<br>
that you use RT as a program listing source via xmltv. This would also<br>
mean you have setup xmltvid's on your channels, and since setting them<br>
up is a pain, you've probably done a scan for channels without deleting<br>
the old ones first.<br>
<br>
Personally i use, EIT so i tend to delete all my channels and rescan.<br>
What i did notice is that they did broadcast incorrect data for the<br>
changeover period, but they quickly sorted that out.<br>
<br>
Assuming you did an update scan, here's my best guess of what happened<br>
with the channel data.<br>
<br>
Myth probably didn't update the channel info correctly, leading to it<br>
still being labelled as Virgin1, when they had started broadcasting<br>
virgin1+1 on that slot. If the xmltv id hadn't been updated then it<br>
would still be setup for the virgin1 xmltv data, and MFDB would duly<br>
put the data for virgin 1 in there. That's my best guess for what<br>
happened there.<br>
<div class="im"><br>
><br>
> Now, combine this with another characteristic of MythTV, that database<br>
> deletes aren't active till a mythfilldatabase run. Then you have the<br>
> situation where the end user *can't delete* 'Virgin 1' and rescan,<br>
> because the deletion isn't flushed before they do a rescan, and the<br>
> channel scanner sees the old channel id, and makes the same mistake again.<br>
><br>
<br>
</div>I'm not sure what you mean here? In the channel scanner if I tell it to<br>
delete the channels, that's what it does, there and then.<br>
<div class="im"><br>
> So, what's the solution... Short term... *Synchronise database deletes<br>
> in channel data before doing a rescan*! This is perhaps a one line<br>
> addition to code somewhere appropriate, and adds only a short pause for<br>
> that operation to the rescan process. This will now make the<br>
> troubleshooting step of 'delete the channel and rescan' actually work.<br>
><br>
> Longer term, be careful with avoiding assuming Channel ID Numbers are<br>
> unique against all situations, because they are only guaranteed to be<br>
> unique at any given time of transmission. Look for where to put in<br>
> checks to see that what MythTV thinks a channel is, is correct. Work out<br>
> what to do when the LCN and channel name for a channel ID number change.<br>
><br>
<br>
</div>Myth generates its own unique chanid as described above.<br>
The fault seems to be that updating channels hasn't worked<br>
as well as it could.<br>
<br>
Hopefully that explains some things...<br>
<font color="#888888"><br>
<br>
Stuart<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
mythtv-dev mailing list<br>
<a href="mailto:mythtv-dev@mythtv.org">mythtv-dev@mythtv.org</a><br>
<a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev</a><br>
</div></div></blockquote></div><br>