[mythtv-users] recordings affecting playback

[Daryl McDonald]

On Thu, Aug 20, 2020 at 2:01 AM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> 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?
>

It is a Seagate Skyhawk (surveillance) 1TB hdd

>
> 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.
> _______________________________________________
> I moved all the recordings from storage3 (Seagate Skyhawk) to storage1 and
> will swap storage 3 with the drive that used to be storage2 a Toshiba, same
> as storage1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200821/99a9270b/attachment.htm>