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.
_______________________________________________
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
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.
_______________________________________________
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