[mythtv-users] ringbuffer errors?

[Jeff Breitner]

On Wed, Jan 1, 2014 at 11:58 AM, Rich West <Rich.West at wesmo.com> wrote:

> Of course, MythTV decides to act up last night.. to the point where
> watching
> a recording of the ball dropping was just not possible (I heard a LOT of "I
> think this is the year we move away from mythtv!" from my other half).
>
> ...

>
> CPU usage & network usage on both the frontend and backend systems were
> extremely low.  From that standpoint, they were basically bored.  Disk I/O
> seemed fine (of course sysstat wasn't installed, and there was essentially
> a
> revolt, so I couldn't dig too deep with the debugging), no disk errors
> reported, and generally the backend appeared healthy (I graph everything
> via
> cacti, including tuner usage, jobs, errors, etc).  I've never had issues
> like this in the past, and we essentially did the same thing around
> Thanksgiving (family over likes the football games) with great success.
> Needless to say, it was very frustrating, and I'm not sure where to even
> begin looking..
>


Have you looked at what you are using for a kernel IO scheduler?

I think there may be some unpleasant interaction with the backend thread
writer and kernel IO scheduling in deadline or cfq.  Noop seems to be the
only way I can avoid having those kinds of messages along with complaints
about waiting 100ms (or more) for video.

Even though XFS does a good job preventing fragmentation, once the file
system gets north of 85% capacity, the performance starts to drop off.
 Does your LiveTV storage fit within 85% capacity?

Finally, has your bios done something stupid and moved your sata drives to
legacy ata?  I found that a bios flash to fix a different flaw changed it,
and only when I was chasing a red herring on this issue did I notice that
ncq was turned off (cat /sys/block/sda/device/queue_depth == 1 ... which is
disabled).

These three things, once resolved, greatly improved things.

I was really locked and loaded to start digging through the source to fix
this problem, but I'm no longer certain this is a major flaw in Myth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140102/cfe7de6f/attachment.html>