Opened 15 years ago
Closed 15 years ago
#7144 closed defect (fixed)
Multirec with HDHR closes video stream when recordings overlap
Reported by: | Owned by: | Nigel | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | MythTV - Recording | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
I recently started utilizing the multirec features of the HDHR and have run into a few issues when recordings actually overlap on the virtual tuners assigned to the HDHR.
The problem occurs when one of the recordings ends while other recordings are still active on other virtual tuners. It appears that when the recording ends, the EnterPowerSavingMode? function is called for the stream handler class. There is a check here to stop this task call from turning off the tuner while other recordings are active, but from what I can tell the function call is not accomplishing what is intended. What ended up happening for me was that there is an overlap of a couple of minutes between the two programs. The 2nd program started out recording properly for the time when both recordings were active, but once the first recording ended, the 2nd recording stopped receiving data as well.
bool HDHRStreamHandler::EnterPowerSavingMode?(void) {
if (!hdhomerun_device_get_video_sock(_hdhomerun_device)) {
VERBOSE(VB_RECORD, LOC + "Ignoring request - video streaming active"); return false;
} else {
return TuneChannel?("none");
}
}
After looking through the HDHR library functions, it appears that this hdhomerun_device_get_video_sock() function will return a pointer to the internal video_socket structure, and will actually create a new video socket if there isn't one allocated. This would result in the task almost always (except in the case of an error building the socket) return a non null value. This in turn will force the tuner to tune to "none" which shuts down the stream to any other listeners.
I haven't had a chance to look for a solution to this yet, I just thought I'd post this here for anyone else who may be more familiar with the libraries and code.
I have attached the relevant section of the backend log when the recordings overlapped. I've attempted to grep out the useful info, but I can post the entire log if there's anything else that would be helpful in verifying this.
Attachments (3)
Change History (9)
Changed 15 years ago by
Attachment: | mythbackend.log added |
---|
comment:1 Changed 15 years ago by
While looking through the logs I also noticed that the refcount for the HDHRStreamHandler never decremented. Traced it back to here where the iterators are dereferenced and decremented, but since there were no parenthesis to force the order of operations, it was actually decrementing the iterator instead.
Index: hdhrstreamhandler.cpp =================================================================== --- hdhrstreamhandler.cpp (revision 21864) +++ hdhrstreamhandler.cpp (working copy) @@ -78,7 +78,7 @@
if (*rit > 1) {
ref = NULL;
- *rit--;
+ (*rit)--;
return;
}
Index: dvbstreamhandler.cpp =================================================================== --- dvbstreamhandler.cpp (revision 21864) +++ dvbstreamhandler.cpp (working copy) @@ -66,7 +66,7 @@
if (*rit > 1) {
ref = NULL;
- *rit--;
+ (*rit)--;
return;
}
Changed 15 years ago by
Attachment: | HDHRIterator.patch added |
---|
comment:2 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 Changed 15 years ago by
Owner: | changed from danielk to Nigel |
---|
oops, two bugs & one ticket, reopening for the other bug.
comment:4 Changed 15 years ago by
Resolution: | fixed |
---|---|
Status: | closed → new |
comment:5 Changed 15 years ago by
I had some time this evening so I took Daniel's suggestion and tested out a simple fix to just check if any data streams were open, instead of using the library call to check the video socket. In my basic testing it fixes the issue. I've attached the patch for reference.
Changed 15 years ago by
Attachment: | FixHDHRMultirecOverlap.patch added |
---|
check for stream listeners to determine whether to set tuner to "none" for HDHR powersave
Backend Log