[mythtv-users] Clearing the DAMAGED flag on a recording

Peter Bennett pb.mythtv at gmail.com
Wed Apr 12 13:13:05 UTC 2023


On 4/12/23 03:19, Stephen Worthington wrote:
> Occasionally, I have a bad recording where the DAMAGED flag gets set.
> There are a number of causes for this, such as rain fade on my
> satellite dish, but recently I was having this quite often where
> mythbackend did not start the recording soon enough and a number of
> seconds were missing at the start.  In a lot of those recordings,
> there was enough pre-roll so that the actual start of the recording
> was still captured, so I did not want them to be marked as damaged or
> automatically re-recorded.  So I was manually clearing the DAMAGED
> flag in the database.  Since that is a fiddly and potentially
> dangerous process of manually doing SQL on the database, I decided to
> automate the job.  So I have written myself a Python program that uses
> the MythTV Python bindings to do this.  I have put it on my web server
> in case anyone else would like to use it:
>
> http://www.jsw.gen.nz/mythtv/clear-damaged-flag.py
>
> Put a copy of this in your /usr/local/bin directory and do "chmod +x"
> on it.
>
> To use clear-damaged-flag.py, you need the recordedid of the recording
> that has the DAMAGED flag.  You can find that by going to the
> recording in mythfrontend and using the I key twice, then scrolling
> down if necessary until you can see the "Recorded ID:" value.  Give
> clear-damaged-flag.py that value as a command line parameter and it
> will do the rest.
>
> The program has the ability to log a decent amount of debug data, so
> if you have any problems with it, just add the "-l debug" option on
> the command line and it will log debug output to a
> clear-damaged-flag.py.log file in the same directory.  Then send me a
> copy of that or post the results here.
>
> BTW I have now found and fixed the problem that was causing my
> recordings to not be started properly.  My MythTV box is in my
> bedroom, and it has two very quiet drives it can use overnight so as
> not to wake me.  But the other five recording drives can be quite
> noisy, so I shut them down when I am asleep.  I do that using my
> noisy-drives program, which moves all the noisy drives out of my
> Default storage group and issues an "hdparm -S 12" command to each
> drive to get them to go into sleep mode after a 60 second timeout.
> When I am awake again, noisy-drives issues an "hdparm -S 0" command to
> cancel the sleep timeout, and moves the drives back in the "Default"
> storage group.  Unfortunately, "hdparm -S 0" does not actually wake up
> the drives, so they remained asleep, and when mythbackend wanted to
> use one of them to record on, it searched all the candidate drives for
> which one had the most free space to choose it to record to.  That
> meant it was waiting for all five of the noisy drives to be spun up
> before it could make that decision and start recording.  That delay
> was too long and was preventing recordings from starting on time.  So
> what noisy-drives now does is to forcibly spin up all the sleeping
> drives after it has done the "hdparm -S 0" command.  It does this by
> doing a dd command to read the first block of the drive, uncached so
> it really will be read from the drive.  The dd command looks like
> this:
>
> dd if=/dev/sd<x> bs=4096 count=1 of=/dev/null iflag=direct
>
> I have put noisy-drives.py on my web server also, should anyone be
> interested in it:
>
> http://www.jsw.gen.nz/mythtv/noisy-drives.py
>
> It is not written for general use - it has specific options in it that
> are likely only found on my system.  But those settings are
> configurable in the configuration section of the code at the top of
> the file, so it may be useful to anyone with enough Python knowledge.
> _______________________________________________

Hi Stephen

This may help :

A couple of years ago I added some settings to reduce the probability of 
recordings being marked as damaged

mythfrontend->Setup->Video->General->General(Advanced)

Maximum Start Gap: The number of seconds that must be missing from the 
front of a recording before it is marked Damaged
Maximum End Gap: Same thing for end of recording.
Minimum Recording Quality: The calculated recording quality below which 
it is marked damaged.

The maximum start gap can be used with a pre-roll. You can set them to 
the same value, so that if the entire show is present it will not be 
marked as damaged.

Peter






More information about the mythtv-users mailing list