[mythtv-users] recordings affecting playback

[Stephen Worthington]

On Wed, 19 Aug 2020 22:44:22 -0400, you wrote:

>This only happens once a week, because I only have multiple recordings on
>Wed. evenings. Watching the (earlier recorded) news while two other
>recordings are in progress results in momentary freezes and accelerated
>catch-ups. Here are some logs:  https://paste.ubuntu.com/p/BCyHYXtH6h/
>(frontend)
>and: https://paste.ubuntu.com/p/h539DKRnnr/  (backend)
>This is a fresh install of Ubuntu 20.04 with Mythtv v31. If we do get a new
>fall season of network TV I'd like to be ready for it. TIA  Daryl

The logs show the problem happening at 21:34 on 19-Aug.  It looks like
the backend was affected also - it was logging slow writes to disk. It
is possible that those recordings may have been damaged by that. There
seem to be two recordings happening at the same time on the same
drive, and the recording being played back at the time is also on that
same drive, mounted on /mnt/storage3.

So what sort of drive is it?  I would have expected that most modern
hard drives would have coped with two recordings and one playback at
the same time.  My experience says that it takes three recordings and
a playback to cause problems like this.  Is there something else also
happening on that drive at the same time?  Is your operating system
and/or database also on that drive?

In any case, the solution is likely to be that you will need to spread
the load out by recording to different drives.  So you would need to
add another recording drive, and make sure that the settings for
recordings will prefer to spread them out over all recording drives -
I think that would mean using the "Balanced disk I/O" setting.

On possibility is that your drive is a shingled drive.  WD have
recently admitted that they were selling SMR drives to customers
without telling them they were shingled:

https://blocksandfiles.com/2020/04/20/western-digital-smr-drives-statement/
https://hexus.net/tech/news/storage/143725-wd-red-hdd-naming-convention-makes-smr-choices-clearer/

SMR drives basically stop for significant periods whenever they have
to re-write shingled tracks.  When it happens, the drive appears to
hang when a read or write is started, and that read or write does not
happen until the drive finishes its shingled track rewrites.  The
worst case times for the rewriting process vary between drives, but
can be up to 60 seconds or more, which is way too long for mythbackend
which will run out of buffer space for its writes.  And, of course,
playback would stall also every time a rewrite happened.  So if the
drive is shingled, it is unsuitable for use as a recording drive and
should be replaced with a normal CMR drive.  You could keep an SMR
drive for storage of recordings and playing them back - they are fine
for that as they will not be written to while playback is happening,
so there will not be any shingled track rewriting going on.  You would
just need to do the recordings to a CMR drive and then move them to
the shingled drive later when MythTV was not busy.  The recordings on
the shingled drive would need to be in a different storage group (not
"Default") so that mythbackend would not record to that storage group.
I have my shingled drives in an "archive" storage group, and I have
written myself a Python program (mythsgu) that can move recording
files to the archive storage group safely - it pauses when mythbackend
says it is busy.