<p><br>
On Feb 10, 2012 9:56 PM, "John Drescher" <<a href="mailto:drescherjm@gmail.com">drescherjm@gmail.com</a>> wrote:<br>
><br>
> On Fri, Feb 10, 2012 at 4:55 PM, Marco Quezada <<a href="mailto:mellamanjefe@gmail.com">mellamanjefe@gmail.com</a>> wrote:<br>
> >>> I was not aware that myth would search through all the listed<br>
> >>> directories in storage groups to look for recordings, that is great<br>
> >>> design and helps me understand a little better how to take advantage<br>
> >>> of them. So correct me if I'm wrong but I if I create a user job<br>
> >>> (simple script) to run after the commercial flagging that copies the<br>
> >>> flagged show to the NAS I should get what I need, right? (as long as I<br>
> >>> set up the storage groups correctly).<br>
> >>><br>
> ><br>
> >>Exactly.<br>
> >><br>
> >>Having 2 Storage Groups allows you to specify that MythTV should only<br>
> >>record to the local dirs (in the Default group), but MythTV will still<br>
> >>find the recordings after you move them to non-local dirs in another group.<br>
> >><br>
> >>However, you will want to remember to remove the original file after you<br>
> >>copy it over. I'm pretty sure you know that, but just wanted to say it<br>
> >>explicitly since you said, "copies."<br>
> >><br>
> >>Also, note that if you fill up the local directories, MythTV will begin<br>
> >>to expire recordings from those directories--and not from the remote<br>
> >>directories--since it's only allowed to write to the local directories.<br>
> >>Note, though, that the same would hold true even if all the directories<br>
> >>are in the recording (Default) storage group. So, just make sure you<br>
> >>have a sufficiently large local file system to handle the recordings<br>
> >>until you've gotten them moved.<br>
> ><br>
> >>Mike<br>
> ><br>
> > Great, yes I move the files but thanks for clarifying that they should<br>
> > be removed afterwards.<br>
> > If it helps others, here is what my entry in the backend settings<br>
> > looks like for user job #1:<br>
> ><br>
> > /usr/local/bin/moveFlaggedRecording.sh %DIR% %FILE% /data/mythtv/recordings<br>
> ><br>
> > And the very simple script (moveFlaggedRecordings.sh) looks like so:<br>
> ><br>
> > #!/bin/sh<br>
> ><br>
> > SRCDIR=$1<br>
> > SRCFILE=$2<br>
> > DESTDIR=$3<br>
> ><br>
> > #Only move the file if it is not already in the destination<br>
> ><br>
> > if [ ! -f $DESTDIR/$SRCFILE ]; then<br>
> > # move the file and associated snaphots<br>
> > mv $SRCDIR/$SRCFILE* $DESTDIR/<br>
> > fi<br>
> ><br>
> ><br>
> ><br>
> > Now I am tackling a scheduler issue...<br>
> ><br>
><br>
> How about rsync with the --remove-source-files parameter?<br>
><br>
> This will verify that the files are the same and then delete the file<br>
> from the sending side.<br>
> John<br>
> _______________________________________________<br>
> mythtv-users mailing list<br>
> <a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
> <a href="http://www.mythtv.org/mailman/listinfo/mythtv-users">http://www.mythtv.org/mailman/listinfo/mythtv-users</a><br></p>
<p>Thanks, I will look into the rsync command. I would like to mention that in the script I posted above that the mount point for the destination is at /data so that as mentioned earlier the move will fail if the directory is not mounted. Also, the script adds the slashes to the path in case they were not specified when the script was called. I will also look into the ionice and size allocation.</p>
<p>-Marco</p>