Opened 14 years ago
Closed 12 years ago
Last modified 12 years ago
#8211 closed defect (Won't Fix)
Incorrect channel change with a channel group and multiple sources
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.25 |
Component: | MythTV - General | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
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 14 years ago by
comment:2 Changed 14 years ago by
Milestone: | 0.24 → unknown |
---|
Please do not set milestones, see ticket howto.
comment:3 Changed 14 years ago by
Owner: | changed from Isaac Richards to danielk |
---|---|
Status: | new → assigned |
Version: | 0.22-fixes → head |
comment:4 Changed 14 years ago by
Owner: | danielk deleted |
---|---|
Status: | assigned → new |
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 14 years ago by
Owner: | set to danielk |
---|---|
Status: | new → assigned |
comment:6 Changed 13 years ago by
Milestone: | unknown → 0.25 |
---|
comment:8 Changed 13 years ago by
Fixes #6948. Refs #8211. Fixes a few bugs in channel browse mode.
Branch: master Changeset: d14b660c168b3ead0ce0ea8bec49243325e73047
comment:9 Changed 13 years ago by
Status: | assigned → infoneeded |
---|
Scott, does this problem still exist after [d14b660c] ?
comment:10 Changed 13 years ago by
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 13 years ago by
Status: | infoneeded → assigned |
---|
comment:12 Changed 12 years ago by
Resolution: | → Won't Fix |
---|---|
Status: | assigned → closed |
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 12 years ago by
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
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: