[mythtv] [mythtv-commits] Ticket #6600: Apparent design flaw in handling changes on channel structure in DVB transmisions.

[John Barberio]

Stuart Auchterlonie stuarta at squashedfrog.net wrote at Fri Jun 5  
16:01:24 UTC 2009
> On Wed, Jun 03, 2009 at 11:20:42AM -0000, MythTV wrote:
> > #6600: Apparent design flaw in handling changes on channel  
> structure in DVB
> > transmisions.
> > -------------------------------------- 
> +-------------------------------------
> >  Reporter:  barberio at lineone.net      |       Owner:  danielk
> >      Type:  defect                    |      Status:  new
> >  Priority:  major                     |   Milestone:  unknown
> > Component:  MythTV - Channel Scanner  |     Version:  0.21-fixes
> >  Severity:  high                      |     Mlocked:  0
> > -------------------------------------- 
> +-------------------------------------
> >  Attention needs to be drawn to the bad user experience of
> >  http://www.gossamer-threads.com/lists/mythtv/users/383253
> >  which is something that hit all UK users of MythTV with the  
> lineup changes
> >  that happen regularly on DVB-T here.
>
> Having read that entire thread there were clearly 2 issues.
> 1. no signal on the mux holding the new channel
> 2. they did incorrectly signal that there wasn't EIT data available
> on the new virgin1 channel
>

This isn't the issue at all, and appears to be a very strange reading  
of it considering what the work around was to fix it.

To refresh your memory, the work around to fix the problem was 1)  
Delete all channel data, 2) flush out those deletes to the database  
from the command line, 3) Perform a full rescan.

Now, if it were either of a signal problem or lacking EIT data, then  
step 3 of that *would have failed*! (And also, our other set top boxes  
which managed to pick up the line up change wouldn't have either.)

> >
> >  This is a pretty major design flaw, that Myth can't handle lineup  
> changes,
> >  and keeps storing the old channel data even when it's wrong, and  
> the
>
> This is just wrong. It doesn't "keep storing" channel data. It's  
> stored
> once at setup time. If you were using mythfilldatabase to populate  
> your
> channels then it's quite likely that the source was slack in adding  
> the
> new virgin1 changes.

The source never adds the channels at all. This problem lasted weeks  
after the lineup change, and wasn't fixed by rescans, or after rescans  
at any time. The only way that the lineup data on Myth was synced to  
the one transmitted was to use the above work around. That's  
considerable 'slack in adding the new changes'.

> We used to dynamically adjust the channels based on the signalling  
> info.
> This worked fine in the UK, but in other countries, when their  
> channels
> go "off-air" they are removed from the signalling tables.
>
> The consequence of this is the channels would constantly be added and
> removed, which plays havoc with recording schedules. So mythtv was  
> changed
> to not automatically update the channel listing.

Again, I think you're misreading the issue here substantially.

When the user performs a channel scan, the user expects that the  
channel lineup on mythtv should match that which is being broadcast. I  
can understand not wanting to delete channels which no longer exist in  
the broadcast lineup, to support broadcasters who send out bad DVB-SI  
by taking timeshare channels out of the EIT. I would prefer that you  
support those broadcasters with an optional 'do not delete absent  
channels during scan' configuration.

But when a channel that exists in the stored lineup is superseded by a  
different channel, you do not want the old channel data to overwrite  
the new channel data! After a user initiated channel scan, new channel  
data should overwrite old channel data. That's something the user  
expects, and I'd consider it basic functionality.

What appears to have happened with the Virgin1 failure, is that MythTV  
interpreted the change as the channel disappearing from the EIT of one  
MUX, and a 'new' channel with the same name, lcn and pid appearing in  
a different Mux's EIT. Under the current behaviour, Myth kept the old  
channel data, doesn't know what to do with the 'new' one so just  
buries it.  This was complicated due to the video and audio streams of  
the old channel being reused for a +1 time shift of the channel on the  
old mux. Which lead to Myth having a 'functional' channel that had  
audio and video time shifted by one hour from the program information  
it was presenting, leading to lots of user confusion, and wrong  
programs getting recorded.

The odd thing here, is I think that by attempting to support the non- 
standards following behaviour of some broadcasters, you've managed to  
break support for standards following broadcasters.

   - John

(Who still can't understand why this isn't in a bug report. Forcing  
people to file reports of myth not working properly to come defend  
their 'opinion about it' on the developers mailing list is very poor  
project management.)