[mythtv] Ticket #10414: HDHomeRun: Bad Recordings (was: Bad Recordings - Choppy Playback)

Tom Lichti tom at redpepperracing.com
Sat Mar 10 21:40:51 UTC 2012

On Sat, Mar 10, 2012 at 11:41 AM, Daniel Kristjansson
<danielk at cuymedia.net> wrote:
> On Fri, 2012-03-09 at 13:17 -0500, Tom Lichti wrote:
>> On Fri, Mar 9, 2012 at 12:44 PM, Derek Atkins <warlord at mit.edu> wrote:
>> > Tom Lichti <tom at redpepperracing.com> writes:
>> I'm trying to rule that out. I don't think it's network or interrupts,
>> I have all Gig-E networking, and the backend is actually a server,
>> Dell Poweredge SC1435, so the only thing I can see is it being the
>> disk. I'll try putting a storage group on another disk and test that
>> and report back.
> I doubt it is the disk. 0.25 dynamically resizes it's buffer up to
> about 128 MB per recording vs the user specified buffer that defaulted
> to 9.6MB in 0.24.
> I was able to reproduce a problem with old firmware using udp
> streaming, but with newer firmware employing rtp streaming I
> can not reproduce the issue. I'm also not seeing the high CPU
> usage reported. I see about 15% CPU usage with two recordings.
> Can you take a look at this:
>  http://www.cyberciti.biz/faq/linux-tcp-tuning/
> And tell me if increasing the rmem_max helps?
> libmythhdhomerun tries to increase the socket buffer
> on startup, but perhaps the rmem_max is set low on
> your system? Mine is set to 131071000.

I did all the things recommended on that page, with very little change
in behaviour. 4 concurrent HDHR recordings, and all of them are
definitely affected. It is better, again, but still not acceptable.
CPU is about 15% per recording, give or take. No issues noticed in
atop in terms of disk or network utilization. How do we tell if it is
using rtp or not? That could be the problem. I too am on the latest
HDHR firmware, for the record. I am more than willing to test any
patches, if necessary.


More information about the mythtv-dev mailing list