[mythtv-users] Storage Groups, free space, (and auto-expire?)

[Michael T. Dean]

On 10/24/2007 09:56 AM, Brian Guilfoos wrote:
> Ryan Steffes wrote:
>   
>> The "easiest" way is a simple script run at regular intervals that
>> checks mythshutdown to see if things are idle, then checks disk space
>> to see if something is getting full, then proceeds to move files from
>> the smaller drive to the larger drive.  If they are in the same
>> storage group, which drive they are on doesn't matter much.
>>     
> I knew somebody here would have useful info.  This was exactly what I
> was thinking of, except I wasn't aware of what mythshutdown was capable
> of (and it's *very* useful for this).  It should be pretty trivial to
> run "mythshutdown -s", parse the return code, and then mv files around
> as needed.
>   

Note, though, that if your recording directories are not accessible to
all backends, you /must/ modify the hostname when you move a recording
from a directory on one hostname to a directory on another.

> As I only have one Storage Group, I could easily automate what I'm doing
> manually every few days now.  If you've got multiple storage groups, I
> still think you'd need to query the database to make sure you only move
> recordings around within that SG.

No.  If a recording is not found in the directories of the specified
storage group, Myth punts and looks at all (locally accessible) storage
groups (directories for the current backend).   So, there's no need to
change the storage group or to be limited to moving only within storage
groups.

>   It seems you could still do that in a
> bash script with a "mysql --execute" command.  Again, I'm willing to
> work on something more robust if there is interest.

If you write a script that you wish to be included in the MythTV source
distribution, please do so using the Perl bindings.  They provide all
the capability you need for finding information about the recordings and
the storage groups--you'd basically just have to provide the code to do
the actual moving of the file and the logic for when to do it.

mythrename.pl is a very good example of the way to use the bindings. 
myth_archive_job.pl is a good example of how to move recordings (though
use the bindings to get Storage Group information.  You could either
extend MythTV::StorageGroup to provide usage information (probably the
better approach, IMHO), or just write the usage monitoring into the script.

If you do this, we could get rid of the "legacy" myth_archive_job.pl
script.  We need to rewrite all the scripts that don't use the bindings
to use them or we need to just delete those scripts, so this would be a
good thing.

The scripts ipodexport.pl, mythrename.pl, dvbradioexport.pl,
optimize_mythdb.pl, channel_icons.pl (and myth_upcoming_recordings.pl
and myth_recent_recordings.pl, if you have the patches from #4049) all
use the bindings.  The scripts trailer.pl, myth_archive_job.pl,
grabukicons.pl, myth.find_orphans.pl, myth.rebuilddatabase.pl,
mythname.pl, mythmaillog.pl, mythencode.pl, change-channel-lirc.pl,
d10control.pl, and mplayernetwork.pl and osx-{bundler,packager}.pl do
not use the bindings, so they would be bad examples to use (except for
the moving/logic from myth_archive_job.pl).

See http://www.gossamer-threads.com/lists/mythtv/commits/239035#239035
for the best info on storage groups.  See, especially, "<spoiler, ie.
not in the current code>" and feel free to implement that, instead, for
a /much/ more capable solution.  Doing that /and/ adding GUI control to
the frontend for moving/archiving recordings would be a very nice
addition (and save someone--likely Chris Pinkham) a lot of time.  See,
also http://www.gossamer-threads.com/lists/mythtv/users/256679#256679
and http://www.gossamer-threads.com/lists/mythtv/users/269092#269092 for
a way to influence the choice of dirs used.

Mike