Opened 14 years ago

Closed 14 years ago

Last modified 12 years ago

#13 closed defect (fixed)

Tune to an on air channel when the current channel is unavailable.

Reported by: stuarta@… Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: low Keywords: channel tuning
Cc: Ticket locked: no


There are a number of conditions where the frontend is unable to start watching LiveTV due to the channel that the backend is currently tuned to.

1) Backend starts up using channel cardinput.startchan but the channel is no longer on air.
2) Backend still running, but the currently tuned channel has gone off air since the frontend last watched LiveTV.
3) As with (2) except the channel may have come back on air, but the state information the backend is holding is no longer current

Case 1: I have a patch for.
Case 3: I suspect is out of date pid/pmt information.

Case 2 & Case 3 are TODO

Attachments (2)

tune2startchannel.0.patch (7.3 KB) - added by stuarta@… 14 years ago.
Patch to tune the backend to an on-air channel
tune2startchannel.1.patch (7.4 KB) - added by stuarta@… 14 years ago.
Updated Patch. Works against svn rev#6987

Download all attachments as: .zip

Change History (9)

Changed 14 years ago by stuarta@…

Attachment: tune2startchannel.0.patch added

Patch to tune the backend to an on-air channel

comment:1 Changed 14 years ago by danielk

Owner: changed from Isaac Richards to danielk

I believe all these problems are solved in the check signal patch:

Can you verify this?

comment:2 Changed 14 years ago by stuarta@…

I've retested this with the latest svn rev 6968

In case 1 the backend tunes to the channel, prints out the message that the channel is off air but takes no further action. The patch from before would still help in this case.

In case 2 where the channel has gone off air. Here in the UK this is normally with channels that timeshare the same frequency.

With the backend running, tuned to the channel as it transitions from on air to off air, I am able to come back and tune to liveTV. BUT, the channel shown is the other channel that timeshares the frequency.

Tuning to another channel and then attempting to tune back, the channel is correctly seen as off air. So this has improved, but isn't yet correct.

I still have to retest case 3, but given the improvements in case 2, I suspect this will work.

Changed 14 years ago by stuarta@…

Attachment: tune2startchannel.1.patch added

Updated Patch. Works against svn rev#6987

comment:3 Changed 14 years ago by danielk

Severity: mediumlow

It looks like I already committed something like the SwitchToInput? part of your code.

I don't like your solution to problem 1. Each tuner would have to share a good channel for that to work. It would make more sense for InitChannel?() to try all the channels on all the inputs of the Tuner until it finds one that works, or at least try one channel on each input, so that completely bogus first channel info gets reset.

BTW Have you tried the signal monitor patch? It should solve problems 2 & 3.

comment:4 Changed 14 years ago by danielk

(In [7063]) References #13.

This should go a long way toward addressing problem 1 in the list of tuning problems.

If a startchan is set we use it. If it is not set we try to use a channel on the current input. If there are no channels defined for the current input,

we try other inputs.

If there are no channels defined at all for the card,

we set the starting channel to '3', which should be fine for tunerless inputs (S-Video capture, etc).

I don't think the channel crawl for a start channel is worth it since we won't have the getting the "Stuck in LiveTV" problem with the signal monitoring feature.

comment:5 Changed 14 years ago by danielk

Resolution: fixed
Status: newclosed

Should be fixed in [7077].

comment:6 Changed 14 years ago by stuarta@…

Resolution: fixed
Status: closedreopened

I've been testing for the last few days.

rev 7064 + signal monitoring patch.

This fixes problem 3 in the list.

When testing case 2 I was able to watch the other channel which timeshares with the channel that went off air, although I was tuned to the logical channel that was off air. I'm happy to leave this part as resolved for now, since proper handling of this requires finishing off interactive tv.

(The following I've tested on 7082 + signal monitoring as well.)

What no longer works is case 1. This is because the channels here in the UK logically go off air, but in practice they are still on air. What happens is the PMT is updated from a video + audio stream to only a data stream(s). So the signal monitoring isn't going to help us here.

When the backend starts up on one of these "off air" channels, it can still get a valid signal lock, but there is no TV service present. There used to be a check in dvbchannel.cpp

if (!chan_opts.pmt.OnAir?()) {

ERROR(QString("Channel #%1 is off air.").arg(chan)); return false;


This did pick up this case. We will need to check something like this when entering live tv.

comment:7 Changed 14 years ago by danielk

Resolution: fixed
Status: reopenedclosed

I've opened a new bug on just the PMT problem and marked this fixed, as the pmt problem is really a new bug.

Note: See TracTickets for help on using tickets.