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


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)

mythfront.log (8.0 KB) - added by… 14 years ago.
Frontend log.
mythback.log (2.1 KB) - added by… 14 years ago.
Backend log at critical point
7123_FREE_RECORDER_igrp_checks.diff (4.4 KB) - added by Shane Shrybman 14 years ago.

Download all attachments as: .zip

Change History (18)

Changed 14 years ago by…

Attachment: mythfront.log added

Frontend log.

Changed 14 years ago by…

Attachment: mythback.log added

Backend log at critical point

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 danielk

Milestone: 0.22unknown
Owner: changed from Isaac Richards to Shane Shrybman
Priority: majorminor
Status: newassigned

comment:3 Changed 14 years ago by stichnot@…

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 Shane Shrybman

Component: MythTV - GeneralMythTV - Video Playback
Milestone: unknown0.22
Severity: mediumlow
Status: assignedstarted

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

comment:7 Changed 14 years ago by Shane Shrybman

Yes, of course, I should have seen that. Thanks for testing it.

comment:8 Changed 14 years ago by Shane Shrybman

Ok, 2nd attempt patch attached.

Changed 14 years ago by Shane Shrybman

comment:9 Changed 14 years ago by stichnot@…

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 shane

Resolution: fixed
Status: startedclosed

(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.

Note: See TracTickets for help on using tickets.