Opened 19 years ago
Closed 19 years ago
Last modified 18 years ago
#13 closed defect (fixed)
Tune to an on air channel when the current channel is unavailable.
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.19 |
Component: | mythtv | Version: | head |
Severity: | low | Keywords: | channel tuning |
Cc: | Ticket locked: | no |
Description
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)
Change History (9)
Changed 19 years ago by
Attachment: | tune2startchannel.0.patch added |
---|
comment:1 Changed 19 years ago by
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 19 years ago by
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 19 years ago by
Attachment: | tune2startchannel.1.patch added |
---|
Updated Patch. Works against svn rev#6987
comment:3 Changed 19 years ago by
Severity: | medium → low |
---|
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 19 years ago by
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 19 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Should be fixed in [7077].
comment:6 Changed 19 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 19 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I've opened a new bug on just the PMT problem and marked this fixed, as the pmt problem is really a new bug.
Patch to tune the backend to an on-air channel