Mailing List Archive

recordings affecting playback
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
Re: recordings affecting playback [ In reply to ]
________________________________
From: Daryl McDonald <darylangela@gmail.com>
Sent: Thursday, 20 August 2020 12:14 pm
To: Discussion about MythTV
Subject: [mythtv-users] recordings affecting playback

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


HD video is probably more than your CPU can handle in software. What does "top" report on FE while playing back?

I CoreContext decoders/mythvdpauhelper.cpp:63 (HaveVDPAU) VDPAUHelp: Supported/available VDPAU decoders:
I CoreContext decoders/mythvaapicontext.cpp:468 (HaveVAAPI) VAAPIDec: Supported/available VAAPI decoders:
I CoreContext decoders/mythnvdeccontext.cpp:519 (HaveNVDEC) NVDEC: No NVDEC decoders found
I CoreContext decoders/mythv4l2m2mcontext.cpp:378 (HaveV4L2Codecs) V4L2_M2M: No V4L2 decoders found
Re: recordings affecting playback [ In reply to ]
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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: recordings affecting playback [ In reply to ]
On Thu, Aug 20, 2020 at 2:01 AM Stephen Worthington <
stephen_agent@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
Re: recordings affecting playback [ In reply to ]
On 8/21/20 7:32 AM, Daryl McDonald wrote:
>
> It is a Seagate Skyhawk (surveillance) 1TB hdd

It's an odd speed.

5900RPM CMR drive,

Doug
Re: recordings affecting playback [ In reply to ]
On Fri, Aug 21, 2020 at 8:02 AM Doug Lytle <support@drdos.info> wrote:

> On 8/21/20 7:32 AM, Daryl McDonald wrote:
>
>
> It is a Seagate Skyhawk (surveillance) 1TB hdd
>
>
> It's an odd speed.
>
> 5900RPM CMR drive,
>
> Doug
>
> _______________________________________________
> Pleased to report that the Toshiba drive seems to have solved the
> porblem... smooth playback wile recording this week. Thanls!