Opened 14 years ago
Closed 14 years ago
#7123 closed defect (fixed)
Problem with tuner groups
| Reported by: | anonymous | Owned by: | Shane Shrybman |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.22 |
| Component: | MythTV - Video Playback | Version: | head |
| Severity: | low | Keywords: | |
| Cc: | Ticket locked: | no |
Description
Backend does not properly identify when one of the two tuners in a tuner group is busy. Tuner 1 a firewire device, tuner 2, 3, and 4 are PVR-150. Tuner 4 and Tuner 1 belong to Firewire-Digital tuner group, while tuner 2 and 3 are standalone tuners. If Tuner 4 is recording, and I attempt to watch TV, I just get a messed up screen for a few moments, and it returns to the menu. I can't get a BT on the backend at the moment, as my wife would kill me if I interrupted the recording, but am including a log of the frontend. Also included is the important section from the backend log. It appears it fails to move on to the next tuner if the last tuner in the tuner group is busy.
Attachments (3)
Change History (18)
Changed 14 years ago by
| Attachment: | mythfront.log added |
|---|
comment:1 Changed 14 years ago by
It appears to look and see that the tuner group is busy, however fails to check and select any other available tuner. Both tuner 2 and tuner 3 are available, however they are both on a separate slave backend. Hope this is enough to help solve, but if not, I can easily reproduce, and when my wife's show is done recording, I'd be happy to create logs for that case.
comment:2 Changed 14 years ago by
| Milestone: | 0.22 → unknown |
|---|---|
| Owner: | changed from Isaac Richards to Shane Shrybman |
| Priority: | major → minor |
| Status: | new → assigned |
comment:3 Changed 14 years ago by
I wonder if this is the same as #6614 that I reported back in June.
comment:4 Changed 14 years ago by
It does look similar, but it appears you are running 0.21-fixes but I'm running 0.22 latest svn. Only real difference I see in the log is that 0.21 at least appeared to look at the other cards, but mine did not log that, however that could be a difference in the debug messages.
comment:5 Changed 14 years ago by
| Component: | MythTV - General → MythTV - Video Playback |
|---|---|
| Milestone: | unknown → 0.22 |
| Severity: | medium → low |
| Status: | assigned → started |
Please try the attached patch and let me know if it helps.
comment:6 Changed 14 years ago by
This did resolve the problem of the frontend crashing when tuner 4 is busy when you start to watch live tv, however one unintended side effect, now, if I'm watching live tv on tuner 1, and I try to switch inputs, tuner 4 is not available, and vice versa. If I switch to Tuner 2 or 3, I can then select either tuner 1 or 4
Changed 14 years ago by
| Attachment: | 7123_FREE_RECORDER_igrp_checks.diff added |
|---|
comment:9 Changed 14 years ago by
My attempted patch for #6614 had the same unintended side effect. Comparing the two patches, I'm convinced that #6614 is the same bug as this one (though this patch is far more elegant than my attempt), so I recommend just closing #6614 as a duplicate. Unfortunately, I retired one of my tuners so I won't be able to test the fix.
comment:10 Changed 14 years ago by
Thanks, I'll pull the patch and test it. Will let you know in a few hours. Thanks again!
comment:11 Changed 14 years ago by
Ok, got the testing all done, and it works perfect! Thank you much! Excellent job! Now accurately detects all tuners busy when they are, and brings up the message to pick an in-progress program when turning on live-tv with all tuners busy.
comment:12 Changed 14 years ago by
I had a a segfault a little bit ago, but unfortunately, I could not capture a backtrace on it. I am running via gdb now, and am trying to reproduce it. Not sure if it's related to this patch or not, as I do have occaisional segfaults. This one occurred as I was exiting live-tv. If I can get it to occur again, I'll take a look and report here, or if it looks unrelated, I may open a new ticket. Thanks.
comment:13 Changed 14 years ago by
Well, 24 hours of running under gdb, not able to reproduce that segfault. Possibly a race condition somewhere, but I really don't believe it's related to this patch.
comment:14 Changed 14 years ago by
Had another segfault like the last, however it was upon exiting watching a recording. I'll open a new ticket, as it has nothing to do with this. This patch appears to work perfectly.
comment:15 Changed 14 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | started → closed |
(In [22114]) Fixes #7123. Do Input Group checks for the GET_*FREE_RECORDER backend queries.
These need to do the igrp checking and return tuners with at least one available input:
void MainServer::HandleGetFreeRecorder?(PlaybackSock? *pbs) void MainServer::HandleGetFreeRecorderCount?(PlaybackSock? *pbs) void MainServer::HandleGetNextFreeRecorder?(QStringList &slist, PlaybackSock? *pbs)
For this function, the igrp checking is already done by the caller (eg. tv_play). It returns a list of non-IsBusy?() tuners.
void MainServer::HandleGetFreeRecorderList?(PlaybackSock? *pbs)
NOTE: GetFreeInputs?() does an IsBusy?() check.
Frontend log.