Opened 13 years ago

Closed 13 years ago

#4213 closed patch (fixed)

HDHomeRun Recording Improvements

Reported by: Bill <cizek@…> Owned by: danielk
Priority: minor Milestone: unknown
Component: mythtv Version: unknown
Severity: medium Keywords:
Cc: Ticket locked: no


My HDHomeRun periodically drops parts of the programs its recording.

The attached patch makes the following changes to reduce the chance that this happens:

  • Add MSG_WAITALL to the recv call to ensure we have a full read from the socket. Otherwise the partial data is dropped.
  • Reduce the chunksize that myth grabs from the hdhomerun buffer in hdhomerun_video_recv.

I've been running this for the last week and it's worked well.


Attachments (2)

065-hdhr.patch (2.0 KB) - added by Bill <cizek@…> 13 years ago.
newhdhr.patch (1.8 KB) - added by Bill <cizek@…> 13 years ago.
New patch for HDHomeRun

Download all attachments as: .zip

Change History (6)

Changed 13 years ago by Bill <cizek@…>

Attachment: 065-hdhr.patch added

comment:1 Changed 13 years ago by danielk

Owner: changed from Isaac Richards to danielk

comment:2 Changed 13 years ago by danielk

Resolution: invalid
Status: newclosed

Bill, please submit this to Nick at SiliconDust? for inclusion upstream in his library and then create a patch updating our hdhomerun lib from the upstream version.

I don't think this is the right approach to take. Even with WAITALL you can still get partial reads due to signals and other kernel events. The proper thing to do is to handle partial reads based on the errno. But if Nick thinks this is better than what is there now in his library I'll accept it.

comment:3 Changed 13 years ago by Bill <cizek@…>

Resolution: invalid
Status: closedreopened


Nick pointed out that the MSG_WAITALL flag is meaningless for UDP, so that part of the patch is moot.

I took another look and found we weren't using HDRingbufferSize. This caused the HDHomerun's buffer to be 3-4 times smaller than the default HD Ring buffer.

I attached a new patch that uses this setting for the HDHomerun buffer.

I've included the chunksize reduction from the original patch -- hdhomerun_video_recv returns a portion of it's internal buffer and blocks it from being used until the next call. This effectively reduces the buffer size by the amount returned. (In the original code the buffer was 2.5 MB and we were reading .5 MB. This resulted in only 2.0 MB of usable buffer space. Worst case, if we tried to read the whole buffer there would be no space left for new data) Since hdhomerun_video_recv is a lightweight function, I don't see any harm in calling it more often with a smaller size.

Changed 13 years ago by Bill <cizek@…>

Attachment: newhdhr.patch added

New patch for HDHomeRun

comment:4 Changed 13 years ago by danielk

Resolution: fixed
Status: reopenedclosed

(In [15031]) Fixes #4213. Makes HDHomeRun buffering more flexible with patch from Bill Cizek.

We used a hardcoded 2.5 MB buffer for reading HDHomeRun. This makes the HDHRRecorder respect the HDRingbufferSize variable which other HD capable recorders use to size the device reading buffer. While 2.5 MB is more than enough in most cases, slower machines may have trouble keeping up at times, so the HDRingbufferSize setting allows us to configure the buffer size.

This also shrinks the size of each read from the buffer from 512 KB to 64 KB. This just allows for slightly better memory usage with typically sized streams.

Note: See TracTickets for help on using tickets.