Opened 14 years ago

Closed 12 years ago

#8941 closed Bug Report - General (Fixed)

Input switching fails when switching to new card

Reported by: markk Owned by: danielk
Priority: minor Milestone: 0.25
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

As reported by markk on mailing list:

I use 2 inputs on my pvr-150. One is connected to a cable stb (Composite 1) and the other is an analogue aerial input (Tuner 1). These are different sources. Whenever I select the analogue tuner, either directly via the 'Input switching' or indirectly via its source, it always switches to the Composite input if I'm on a different card. It uses the correct input if I'm already on that card.

Is this the intended behaviour? The composite input is defined first in the db but the tuner is designated as the default input.

Attachments (4)

8941-v1.patch (3.1 KB) - added by danielk 14 years ago.
untested fix
frontend-1.log (13.1 KB) - added by markk 13 years ago.
backend-1.log (81.1 KB) - added by markk 13 years ago.
8941-v2.patch (503 bytes) - added by danielk 13 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 14 years ago by beirdo

Reporter: changed from danielk to markk
Status: newassigned

Changed 14 years ago by danielk

Attachment: 8941-v1.patch added

untested fix

comment:2 Changed 14 years ago by danielk

(In [26447]) Refs #8941. This fixes a bug in the channel changing code. The code was never being executed because a refactor had moved the setting of testrec to after it's first use. I've verified this with switching channels between two single input cards. But to close the ticket we need someone with a multi-input card to test the fix. Note: I also improved the debugging output a bit, so if it doesn't work the log should be more helpful.

comment:3 Changed 14 years ago by danielk

(In [26448]) Refs #8941. Accidentally committed some unrelated debugging code in [26447] reverting...

Changed 13 years ago by markk

Attachment: frontend-1.log added

Changed 13 years ago by markk

Attachment: backend-1.log added

comment:4 Changed 13 years ago by anonymous

Daniel

I've attached the output of mythfrontend -v channel and mythbackend -v channel, record

In outline: start watching live tv (HDHomeRune DVB-T), bring up OSD menu and select Tuner input of PVR-150. It switches to the composite input of the the PVR-150.

Changing channels directly works fine as does changing inputs when already on viewing using the PVR-150.

The key problem appears to be around 2010-10-04 08:54:04.088 in the backend log. For some reason the backend is looking for the starting channel (23) for the Composite input rather than 5, which is correct for the Tuner input.

Changed 13 years ago by danielk

Attachment: 8941-v2.patch added

comment:5 Changed 13 years ago by danielk

Status: assignedinfoneeded

does the patch resolve the problem?

comment:6 Changed 13 years ago by anonymous

Daniel - sorry, no luck with the patch. The behaviour does seem to have changed slightly in trunk though (unpatched) - it now seems to always start on the last used input and not the Composite input all of the time.

comment:7 Changed 13 years ago by Simon Kenyon <simon@…>

if this is not related then i am sorry

if i change channel using up/down then when i change from one tuner to the next, it "sticks" if i change channel using [0-9]<enter> then up/down use previous channel as starting point

for example:

three tuners:

td-500 receiving digital terrestrial - channels 1-5

pvr-350 receiving output from STB on SVideo input - channels 101-999

dvb-s receiving freesat - channels 20101-20999

if i start on channel 1 and type <up> a number of times i end up at channel 101

if i then type <up> on channel 101 i end up on 102

if i then type <2><0><1><0><1><enter> i end up on channel 20101

if i then type <up> i end up on channel 103

if i then type <up> gazillion times i end up on channel 20101

if i then type <up> i end up on channel 20102

seems as though <up>/<down> records the channel number/input card in a way differently (and incorrectly) to number input

comment:8 Changed 13 years ago by danielk

Milestone: 0.240.25
Status: infoneededassigned

I still may get a chance to look at this before the 0.24. The main obstacle is setting up the test machine. But it's more likely that this will be postponed to 0.25 and then backported.

comment:9 Changed 12 years ago by danielk

Status: assignedinfoneeded

Can someone confirm this is still a problem in trunk?

comment:10 Changed 12 years ago by Github

Refs #8941. Make sure we set the channum when switching to a new card with either a specific chanid or inputid.

When switching cards with a chanid or inputid we want to end up on a specific input, but currently this only happens if channum is also set (or there is only one input on the card).

Note: I do not have a setup that allows me to test this code works as intended, but the code should at least not make anything worse.

Branch: master Changeset: 7e4740ea51f62c39029de7f93eb91dac748a54b3

comment:11 Changed 12 years ago by stuartm

Type: defectBug Report - General

comment:12 Changed 12 years ago by danielk

Resolution: Fixed
Status: infoneededclosed

I don't believe this to be a problem in trunk. I don't have a setup that allows me to test, but I'm also not expecting a response from the ticket submitter so I'm closing this as fixed based on code reading alone.

Note: See TracTickets for help on using tickets.