[mythtv] [mythtv-commits] Ticket #6600: Apparent design flaw in handling changes on channel structure in DVB transmisions.
barberio at lineone.net
Fri Jun 26 17:50:13 UTC 2009
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
> > and keeps storing the old channel data even when it's wrong, and
> This is just wrong. It doesn't "keep storing" channel data. It's
> once at setup time. If you were using mythfilldatabase to populate
> channels then it's quite likely that the source was slack in adding
> 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
> This worked fine in the UK, but in other countries, when their
> 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
> 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.
(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
More information about the mythtv-dev