Opened 8 years ago

Closed 6 years ago

Last modified 6 years ago

#8211 closed defect (Won't Fix)

Incorrect channel change with a channel group and multiple sources

Reported by: scottadmi@… Owned by: danielk
Priority: minor Milestone: 0.25
Component: MythTV - General Version: head
Severity: medium Keywords:
Cc: Ticket locked: no


I generally display only favorite channels in the guide when watching live tv (to reduce the clutter) which means when changing channels using the remote (simple channel up/channel down keys) it should only cycle through the favorite channel group.

The problem is, I have multiple input cards with different sources (in my case analog cable and a digital cable). These overlap a large number of channel numbers and as a result it does not correctly handle channel change events when the "favorites" channel group is in use. When I press channel up while watching from the 2nd card, it will instead go the second favorite on the first card.

Digging around the code I discovered the likely cause. In tv_play.cpp, when the m_channellist value is populated, it (correctly) eliminates duplicate channel numbers leaving just one chanid for each station even if the same channel number exists on multiple cards. This list is passed along with the current chanid to GetNextChannel? (in channelutil.cpp) to determine what to change to.

The problem is, in my case the list mostly contains chanids from the first card, so when GetNextChannel? tries to find the current chanid in the list it can't. (As an example, I'm watching channel 13 which is currently chanid 2013, but the list only contains 1013.) Failing to find the current channel, it reverts to the first item in the channel group list and thus incorrectly chooses an early channel on the other card.

The fix seems like it would be to change GetNextChannel? to instead search on a channum (not chanid) and return a channum so channel changing is independent of the card in use. As this function is referred to in multiple places, I lack the personal expertise to fix this in a clean way to avoid interfering with other parts of the code.

Change History (13)

comment:1 Changed 8 years ago by scottadmi@…

A quick fix that incorporates the GetNextChannel? function code modified to use channum (instead of chanid) into the ChangeChannel? function (probably not the perfect solution, but it does the job for now). In libs/libmythtv/tv_play.cpp replace lines 6742 through 6750 with this:

      // Collect channel info
       const ProgramInfo pginfo(*ctx->playingInfo);

       QString old_channum  = pginfo.chanstr;
       ctx->UnlockPlayingInfo(__FILE__, __LINE__);

       DBChanList::const_iterator it = m_channellist.begin();
       for ( ;it != m_channellist.end(); it++)
          if ( it->channum == old_channum )

       if (it == m_channellist.end()) {
           VERBOSE(VB_IMPORTANT, "ChangeChannel did not find current channel in list.");
           it = m_channellist.begin(); // not in list, pretend we are on first channel

       if (it == m_channellist.end())
           return; // no channels..

       DBChanList::const_iterator start = it;
       bool skip_non_visible = true; // TODO make DB selectable

       if (CHANNEL_DIRECTION_DOWN == direction)
               if (it == m_channellist.begin())
                   it = find(m_channellist.begin(), m_channellist.end(),
           while ((it != start) && (skip_non_visible && !it->visible));
       else if ((CHANNEL_DIRECTION_UP == direction) || (CHANNEL_DIRECTION_FAVORITE == direction))
               if (it == m_channellist.end())
                   it = m_channellist.begin();
           while ((it != start) && (skip_non_visible && !it->visible));
       ChangeChannel(ctx, 0, it->channum);


comment:2 Changed 8 years ago by robertm

Milestone: 0.24unknown

Please do not set milestones, see ticket howto.

comment:3 Changed 8 years ago by danielk

Owner: changed from Isaac Richards to danielk
Status: newassigned
Version: 0.22-fixeshead

comment:4 Changed 8 years ago by danielk

Owner: danielk deleted
Status: assignednew

Scott, using channum would cause it's own problems. I think the proper thing to do is to not eliminate duplicates, but of course that will have ripple effects.

For now you can rename your channels so each one has a unique channum as a work around.

comment:5 Changed 8 years ago by robertm

Owner: set to danielk
Status: newassigned

comment:6 Changed 8 years ago by danielk

Milestone: unknown0.25

comment:7 Changed 8 years ago by stuartm

Milestone: 0.25

Milestone 0.25 deleted

comment:8 Changed 7 years ago by Github

Fixes #6948. Refs #8211. Fixes a few bugs in channel browse mode.

Branch: master Changeset: d14b660c168b3ead0ce0ea8bec49243325e73047

comment:9 Changed 7 years ago by danielk

Status: assignedinfoneeded

Scott, does this problem still exist after [d14b660c] ?

comment:10 Changed 7 years ago 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.

comment:11 Changed 7 years ago by Raymond Wagner

Status: infoneededassigned

comment:12 Changed 6 years ago by danielk

Resolution: Won't Fix
Status: assignedclosed

Channel Groups are pretty much broken by design, so I'm going to mark this as won't fix.

If someone wants to submit a patch to either remove channel groups or implement them properly please open a new ticket and I'll review the patch.

comment:13 Changed 6 years ago by Github

Refs #6948. Refs #8211. Fixes channel list bug introduced in d14b660c.

To fix problems elsewhere this commit filtered out channels that were not connected to any card. But this function is used during setup when connecting an input to a card, at which point this filtering causes problem in filling the start channel field.

This introduces a new function for use during setup which doesn't apply this filterning.

Branch: master Changeset: 194ad69243eb6d403e7d29676276c86cab4c7905

Note: See TracTickets for help on using tickets.