[mythtv-users] HD playback slight jitter every 10 secs

[Mike Thomas]

On Mon, 10 Feb 2014 22:45:24 +0100
Angela <angela.schmid at wolke7.net> wrote:
> Have I look at https://code.mythtv.org/trac/ticket/12016 which
> discusses jitter with viewing in-progress recordings.

Hi Angela,

Thank you for pointing out the bug. I'm glad someone else has noticed
this, not that I mean you any ill.

It was interesting to see your experiences with ext3. I'm not surprised
that you are still getting problems with ext3 because it is notoriously
slow. Were you using a 5400rpm drive? Do you find you get more stutters
if you record two programmes simultaneously? Nevertheless I am
surprised that an SSD doesn't help.

The disk performance of modern Linux kernels is rather odd. It comes up
on LKML fairly often. I hit it daily when I perform large jobs on local
disk and then try to use NFS. The NFS activity becomes quite jerky even
though my CPUs are largely idle. Even if you have an SSD for your
database, if your video files are on a 5400rpm disk, this phenomenon
could be what it tipping your system over the edge. You might like to
try configuring a new video storage directory on your SSD and repeat the
test.

Yesterday I upgraded my main MythTV system and I noticed the stuttering
again. However, this is a completely different problem. I mention it
here because the user-visible symptoms are the same and are worth
discussing in light of your findings.

If I watch a recording in progress, I see no stuttering so long as I
watch the programme about a minute or more behind live. This is what
you did in your bug report, albeit by 5 minutes. Once I tip over the
threshold I see stutters every 10 seconds. If I pause it for a few
seconds before resuming playback it the stuttering disappears. In this
way I can work out how far behind real-time I must be to see smooth
playback.

The difference between these stutters and the ones we are talking about
here are the copious messages (here copied from my earlier thread):

ProcessRequest ringbuffer.cpp:1035 (WaitForReadsAllowed) -
RingBuf(/export/home50/video/1003_20140116185400.mpg): Taking too long
to be allowed to read..
ProcessRequest ringbuffer.cpp:1098 (WaitForAvail) -
RingBuf(/export/home50/video/1010_20140116191706.mpg): Waited XXX
seconds for data to become available... 816100 < 917504

Put together with your findings on file linking ISTM we are seeing
mythbackend perform an excessively long *sequence* of steps when it is
transmitting live data still in the ring buffer (or recently left), but
not when it is just recording and playing back data from the same inode.
Although the work is the same in both cases it looks like mythbackend
can perform much of the recording and transmission steps simultaneously
under normal circumstances, but in other cases the recorder and
transmitter threads spend too much time waiting for locks to clear.

If this is the case it would explain why my patch makes a difference.
Did it work for you? Does it improve things further if you modify my
patch further by using INSERT DELAYED? I'd expect the latter to cause
other playback problems, but it might help draw out this problem.

Yours,

Mike.

PS. The refresh rate mismatch discussed in the bug commentary has
nothing whatsoever to do with this problem. I have a Sharp TV which
can't do 25fps, but does 24fps instead. That stutters every second or so
and is very annoying. When I tickle the MythTV bug we are discussing
here, I see two lots of stutters as would be expected if the problems
were independent.