[mythtv-users] how to disable the delete recording option ?

Brian Guilfoos mythtv at guilfoos.com
Wed Apr 11 13:51:27 UTC 2007


Pietralla, Siegfried P wrote:
> so now i'm done - i have a simple way to protect selected recordings
> from deletion, and all done through the standard interface without the
> need for any scripting or application changes. as a bonus, this also
> protects me from stupid mistakes when using the command line.

This is pretty clever.  I haven't tested it yet, but it looks promising
enough that I SSH'd into my network from work and set everything up.
Even wrote up a page on the wiki about this, as it seems like a really
useful hack.

http://www.mythtv.org/wiki/index.php/Protect_Recordings_From_Deletion

One question I have... based on reading the documentation for "chattr"
(quoted in the wiki), it seems like this might cause transcoding to go a
little wonky.  I'll test it out myself tonight, but looking at the
source (mythtv/programs/mythtranscode/main.cpp) it looks like it'd
transcode fine, but then have an error a) renaming the old file to
"filename.old" and then b) deleting "filename.old" (since it doesn't
exist).  So it looks like it'd leave an orphan file (the original) and
successfully update the DB to point to the new .nuv file.  If the
original recording is .nuv, then I'm not sure what it'd do - it looks
like you'd have your original recording (sans cutlist/bookmarks) and the
transcoded file orphaned out on the file system.

It seems like you could fix any problems by wrapping "mythtranscode" in
a script that calls "lsattr" to check if "i" is set, unsets it if
necessary, transcodes the file, then *resets* the protection (again, if
necessary).  Or perhaps simpler, modify mythtranscode to handle that
itself.  If it gets to that, it's probably worth modifying MythTV to do
the protection itself, rather than utilizing User Jobs - and maybe even
to make it a flag in the database, rather than twiddling bits at the
filesystem level.


More information about the mythtv-users mailing list