Opened 15 years ago
Closed 13 years ago
Last modified 12 years ago
#6948 closed defect (fixed)
LiveTV browse mode starts on wrong channel
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.25 |
Component: | MythTV - General | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
I have two capture cards, one analog and one digital. Hence i have two video sources. Analog card source contain channel 1-10. Digital card source contain channel 1-20.
If i'm tuned to channel 15(only available on digital source) and start browsing, channel 14 or 16 is shown, depending if i press up or down arrow.
If i'm on channel 9(available on both sources) and start browsing, channel 2 or 20 is shown(the channels surrounding channel 1), depending if i press up and down arrow.
BUG: Don't show channels surrounding the tuned channel if that channel exist in two video sources.
Additional info: I found one thing that i dont know if it could be to some help. In MythWeb, Channel Info, i have all channels listed with the according sourceid, grouped by channum. On some channels sourceid 1 comes before sourceid 2, and on some channels sourceid 2 is before sourceid 1. What is strange is that the channels that have sourceid 2 before sourceid 1 everything work as expected with browse mode. And the channels that are listed with sourceid 1 before sourceid 2 show the buggy behavior in browse mode.
Attachments (3)
Change History (24)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
Dont know if it is a duplicate. I have no problem browsing or changing channels after it occurs. The only problem is that browsing dont start on the surrounding channels from the currently tuned one.
comment:3 Changed 14 years ago by
Owner: | changed from Isaac Richards to Shane Shrybman |
---|---|
Status: | new → assigned |
Shane, if you don't have time for this one before 0.22, please set the milestone to unknown and feel free to pass it on to me if your not interested in it.
comment:4 Changed 14 years ago by
Milestone: | 0.22 → unknown |
---|
comment:5 Changed 14 years ago by
Owner: | changed from Shane Shrybman to danielk |
---|---|
Status: | assigned → accepted |
comment:6 Changed 13 years ago by
This kind of problem only occurs when "Browse all channels" is selected so this is a variation of the problem described in #8211.
As a workaround I recommend not having any duplicate channum's in your database if you use either the "Browse all channels" feature or the "Channel Groups" feature.
comment:7 Changed 13 years ago by
Milestone: | unknown → 0.25 |
---|
comment:9 Changed 13 years ago by
The attached patch fixes the starting channel in browse mode problem with "browse all channels" enabled and duplicate channel numbers, but some channel changes fail and you must use the "O" keybinding to enter browse mode.
Changed 13 years ago by
Attachment: | 6948-v2.patch added |
---|
Allows you to enter browse mode using up and down arrows, not just using the browse keybinding.
comment:10 Changed 13 years ago by
I was just asking about this on mythtv-users:
http://www.gossamer-threads.com/lists/mythtv/users/462443
My setup:
0.24.0+fixes27373
3 x DVB Cards 1 x Source
No duplicate channel numbers.
Entering browse mode with up/down arrow brings up the first/last channel respectively on the OSD. Interstingly, this only happens the FIRST time you enter browse mode by up/down arrow after starting livetv. After you have changed channel from browse mode, entering browse mode again through up/down arrow brings up the next/previous channel on the OSD (correct behaviour). Running mythfrontend -v all showed the following differences:
First entering of browse mode (while on channel 109):
2010-12-01 21:47:19.308 BrowseDispInfo?() 2010-12-01 21:47:19.308 BrowseStart?() 2010-12-01 21:47:19.308 MythSocket?(7fef01817a20:61): readBlock(0x140664265298656, 154080) called 2010-12-01 21:47:19.309 MythSocket?(7fef0c052250:31): write -> 31 83 QUERY_RECORDER 3[]:[]GET_NEXT_PROGRAM_INFO[]:[][]:[]0[]:[]1[]:[]2010-12-01T21:47:19
Subsequent entry of browse mode after selecting the first channel it popped up with (101):
2010-12-01 21:47:31.080 BrowseStart?() 2010-12-01 21:47:31.080 MythSocket?(7fef01817a20:61): readBlock(0x140664265748588, 217256) called 2010-12-01 21:47:31.080 MythSocket?(7fef01817a20:61): readBlock(0x140664265751484, 214360) called 2010-12-01 21:47:31.082 MythSocket?(7fef0c052250:31): write -> 31 88 QUERY_RECORDER 3[]:[]GET_NEXT_PROGRAM_INFO[]:[]101[]:[]101[]:[]1[]:[]2010-12-01T21:47:31
I noticed on the first entry after starting livetv, it calls GET_NEXT_PROGRAM_INFO with one of the ARGS being 0. After changing channels, it calls GET_NEXT_PROGRAM_INFO with an argument of the current channel number.
If you need any further info, please let me know.
comment:11 Changed 13 years ago by
pmcenery, was this with or without the patch? Does this still happen when the patch is added/removed?
comment:12 Changed 13 years ago by
Dan. I'm just building with the v2 patch now. Will report back as soon as its built...
comment:13 Changed 13 years ago by
i have v2 patch applied.
with browse all channels disabled, the arrow keys do not enter browse mode.
with browse all channels enabled, the arrow keys do enter browse mode.
the setting "always use browse mode in livetv" was enabled in both cases.
comment:14 Changed 13 years ago by
Dan. Sorry for the delay in reply. I added the patch to 0.24.0+fixes27373. Its just easier for me to rebuild the mythbuntu packages to test on my system. The patch went in with some fuzz, but I'm not sure its correct. Hitting the up/down arrow brings up the OSD, but no channel names appear. It appears a little broken. What revision did you intend the patch to be applied to?
P.S. the Debian / Ubuntu package with the patch can be found in my PPA:
comment:15 Changed 13 years ago by
one (good in my opinion) side effect of this change is that livetv will start on the last selected tuner. before it always used to revert to the first tuner.
comment:16 Changed 13 years ago by
The patch v2 did not work for me. When I tried to bring up the OSD, it appeared but no channel information appeared. The OSD scrolled but still no channel information appeared. I'm running 0.24 from git.
comment:17 Changed 13 years ago by
See also #9025, #9137 and #9161 . Note that ticket:9161#comment:4 indicates that 6948-v2.patch solved the problem for Simon, and includes a log showing SQL errors with 6948-v2.patch applied at http://code.mythtv.org/trac/attachment/ticket/9161/9161.log .
2010-12-01 22:44:38.223 Error preparing query: SELECT channum, callsign, channel.chanid, atsc_major_chan, atsc_minor_chan, name, icon, mplexid, visible, channel.sourceid, cardinput.cardid, channelgroup.grpid FROM channel LEFT JOIN channelgroup ON channel.chanid = channelgroup.chanid JOIN cardinput ON cardinput.sourceid = channel.sourceid JOIN capturecard ON cardinput.cardid = capturecard.cardid WHERE sourceid='2' 2010-12-01 22:44:38.224 Driver error was [2/1052]: QMYSQL3: Unable to prepare statement Database error was: Column 'sourceid' in where clause is ambiguous
Changed 13 years ago by
Attachment: | 6948-v3.patch added |
---|
Update patch, applies against master. Otherwise completely untested.
comment:18 Changed 13 years ago by
I have not run the code with the update patch. I just made it apply again, removed a dbcheck change which shouldn't have been there in v2 of the patch and added disambiguation to the SELECT statement based on the log provided in #9161 as pointed out by mdean.
comment:19 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Fixes #6948. Refs #8211. Fixes a few bugs in channel browse mode.
Branch: master Changeset: d14b660c168b3ead0ce0ea8bec49243325e73047
comment:20 Changed 13 years ago by
The problem still exist for me. I could supply logs if that would be any help.
comment:21 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
dup of #6208? (though this one describes a different side effect of the issue)