[mythtv] [mythtv-commits] Ticket #8211: Incorrect channel change with a channel group and multiple sources

[Michael T. Dean]

On 06/02/2011 12:14 PM, Markus Schulz wrote:
> Am Donnerstag, 2. Juni 2011 schrieb MythTV:
>> #8211: Incorrect channel change with a channel group and multiple
>> sources
>> ---------------------------------+----------------------------
>> Reporter:  scottadmi@…          |          Owner:  danielk
>>       Type:  defect               |         Status:  infoneeded
>>   Priority:  minor                |      Milestone:  0.25
>> Component:  MythTV - General     |        Version:  head
>>   Severity:  medium               |     Resolution:
>>   Keywords:                       |  Ticket locked:  0
>> ---------------------------------+----------------------------
>>
>> Comment (by Markus Schulz<msc@…>):
>>
>>   yes, if you have enabled BrowseAllTuners=1 and BrowseChannelGroup=1
>> you still got the first channelgroup entry after start browse-mode.
>> if you disable one of the options, it works as expected.
> but it looks like a problem with building the channel groups.
> if you build a channel group, you select a "channel", but it reflects
> only the channel from one (first?) source (not the same channel from
> another source with same name and number).
>
> Therefore if you are on the other (second?) source and start browse mode
> (inside a channel group) with enabled BrowseChannelGroup=1 it can't find
> the current channel in the current channel group (only channels from the
> other source are inside the group) and you start from the first channel
> (possibly not part of the group).
>
> i know that dev's currently suggest to give the same channel from a
> second/third/.. source a different number to avoid this.

The recommendation is actually to use the same channel number /only/ 
when the 2 channels are the same channel with identical content (i.e. 
channel number is used to tell Live TV which channel to tune, and if you 
have the same channel number on 2 or more channels, Live TV is allowed 
to use any of those channels as they're "equal" in Live TV).  Similarly, 
the call sign should only be the same when the 2 channels are the same 
channel with identical content, since call sign is used to tell the 
recorder which channels to consider for "this channel" recording rules.

However, there was a recommendation that using different channel 
numbers, even when content was identical, may be a workaround for users 
experiencing channel change problems in Live TV where the wrong channel 
is tuned.

>   But thats
> really a pain from user perspective ("Record on this channel" is fixed
> to single source,

"This channel" recording rules use channel call sign, /not/ channel number.

>   memorize more channel numbers, longer epg/browse
> listings, ...).

But in the case of channel numbers, if the channels /should/ be treated 
as different channels, they need different channel numbers--otherwise, 
you could end up on the wrong channel when you tell MythTV to tune 
"channel 3".

> has someone thought about a refactoring of the channel framework to
> something like this:
>
> [Channel] : (ChannNr, ChannName, ChannNetworkName{currently not parsed
> but needed}, Icon, ...)
>     ^
>     |
> [ChannelSource] : (ChannID, ChannNr, SourceID, ServiceID, MPlexID, ...)
>     ^
>     |
> [Multiplex] : (MplexID, SourceID, ...)
>
>
> all EPG informations are assigned to [Channel] and can come from
> different sources. Each Source can have a "quality" value to allow
> preferred recording of "better" sources (i.e. DVB-S>  DVB-T>  analog,
> ..).

The source "quality" is already specified by the order in which capture 
cards are created (for Live TV tuner allocation--when you enable, "Avoid 
conflicts between Live TV and scheduled shows") and the order in which 
inputs are connected (for scheduled recording tuner allocation--when you 
don't tell MythTV inputs are all equivalent by setting input priorities 
and enabling, "Reschedule higher priorities").

> what other aspects should be minded?
> Are there any showstopper issues, i.e. important things currently
> possible but not afterwards?
>
> i know such a refactoring would be very punishing but with a high reward
> in my opinion.

As far as the rest goes...  It seems to me all we need to do is 
incorporate a patch that uses the channel ID in the channel group to 
look up the channel number (since this applies to Live TV) and use that 
when matching channels for browsing within a channel group (as does the 
rest of MythTV's Live TV code).  (And if we ever add the ability to 
schedule recordings on a specific channel group, we will need to match 
the channel call sign from the channel specified in the channel group.)

Does this sound like it would fix the problem you're seeing?

Mike