<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 20, 2020 at 2:01 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 19 Aug 2020 22:44:22 -0400, you wrote:<br>
<br>
>This only happens once a week, because I only have multiple recordings on<br>
>Wed. evenings. Watching the (earlier recorded) news while two other<br>
>recordings are in progress results in momentary freezes and accelerated<br>
>catch-ups. Here are some logs:  <a href="https://paste.ubuntu.com/p/BCyHYXtH6h/" rel="noreferrer" target="_blank">https://paste.ubuntu.com/p/BCyHYXtH6h/</a><br>
>(frontend)<br>
>and: <a href="https://paste.ubuntu.com/p/h539DKRnnr/" rel="noreferrer" target="_blank">https://paste.ubuntu.com/p/h539DKRnnr/</a>  (backend)<br>
>This is a fresh install of Ubuntu 20.04 with Mythtv v31. If we do get a new<br>
>fall season of network TV I'd like to be ready for it. TIA  Daryl<br>
<br>
The logs show the problem happening at 21:34 on 19-Aug.  It looks like<br>
the backend was affected also - it was logging slow writes to disk. It<br>
is possible that those recordings may have been damaged by that. There<br>
seem to be two recordings happening at the same time on the same<br>
drive, and the recording being played back at the time is also on that<br>
same drive, mounted on /mnt/storage3.<br>
<br>
So what sort of drive is it?  I would have expected that most modern<br>
hard drives would have coped with two recordings and one playback at<br>
the same time.  My experience says that it takes three recordings and<br>
a playback to cause problems like this.  Is there something else also<br>
happening on that drive at the same time?  Is your operating system<br>
and/or database also on that drive?<br></blockquote><div><br></div><div>It is a Seagate Skyhawk (surveillance) 1TB hdd </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In any case, the solution is likely to be that you will need to spread<br>
the load out by recording to different drives.  So you would need to<br>
add another recording drive, and make sure that the settings for<br>
recordings will prefer to spread them out over all recording drives -<br>
I think that would mean using the "Balanced disk I/O" setting.<br>
<br>
On possibility is that your drive is a shingled drive.  WD have<br>
recently admitted that they were selling SMR drives to customers<br>
without telling them they were shingled:<br>
<br>
<a href="https://blocksandfiles.com/2020/04/20/western-digital-smr-drives-statement/" rel="noreferrer" target="_blank">https://blocksandfiles.com/2020/04/20/western-digital-smr-drives-statement/</a><br>
<a href="https://hexus.net/tech/news/storage/143725-wd-red-hdd-naming-convention-makes-smr-choices-clearer/" rel="noreferrer" target="_blank">https://hexus.net/tech/news/storage/143725-wd-red-hdd-naming-convention-makes-smr-choices-clearer/</a><br>
<br>
SMR drives basically stop for significant periods whenever they have<br>
to re-write shingled tracks.  When it happens, the drive appears to<br>
hang when a read or write is started, and that read or write does not<br>
happen until the drive finishes its shingled track rewrites.  The<br>
worst case times for the rewriting process vary between drives, but<br>
can be up to 60 seconds or more, which is way too long for mythbackend<br>
which will run out of buffer space for its writes.  And, of course,<br>
playback would stall also every time a rewrite happened.  So if the<br>
drive is shingled, it is unsuitable for use as a recording drive and<br>
should be replaced with a normal CMR drive.  You could keep an SMR<br>
drive for storage of recordings and playing them back - they are fine<br>
for that as they will not be written to while playback is happening,<br>
so there will not be any shingled track rewriting going on.  You would<br>
just need to do the recordings to a CMR drive and then move them to<br>
the shingled drive later when MythTV was not busy.  The recordings on<br>
the shingled drive would need to be in a different storage group (not<br>
"Default") so that mythbackend would not record to that storage group.<br>
I have my shingled drives in an "archive" storage group, and I have<br>
written myself a Python program (mythsgu) that can move recording<br>
files to the archive storage group safely - it pauses when mythbackend<br>
says it is busy.<br>
_______________________________________________<br>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</blockquote></div></div>