[mythtv-users] Record, flag commercials, then move to NAS

Michael T. Dean mtdean at thirdcontact.com
Fri Feb 10 22:13:02 UTC 2012


On 02/10/2012 04:52 PM, Michael Watson wrote:
> On 11/02/2012 7:03 AM, Michael T. Dean wrote:
>> On 02/10/2012 02:37 PM, Pieter De Wit wrote:
>>> On 11/02/2012 08:27, Marco Quezada wrote:
>>>> I have a small setup comprised of a combined backend/frontend using a
>>>> HDHR tuner and directly connected to my TV. This machine mounts
>>>> through NFS its mythTV storage directories on a small NAS machine. So
>>>> when a show is recorded mythTV writes it directly to the NAS. However,
>>>> once the recording ends, then the commercial flagging task begins and
>>>> that means that the BE/FE has to read the video back through the
>>>> network, do the flagging and write back to the NAS.
>>>>
>>>> What I would like instead is to have mythTV record locally on the
>>>> BE/FE machine and do its commercial flagging locally, then once the
>>>> task is complete the flagged recording should be moved to the NAS for
>>>> storage thus minimizing the amount of times the recordings are moved
>>>> across the network. I thought that a user job that includes flagging
>>>> the commercials and then moving the recording is a way to solve this
>>>> but I am not sure how to update the data base so that myth can find
>>>> the recording in its new location after it has been moved.
>>>>
>>>> Does anyone have a script or can suggest a setting that can help me
>>>> accomplish this?
>>> Hey Marco,
>>>
>>> See my script that I posted to the list:
>>>
>>> http://www.mythtv.org/pipermail/mythtv-users/2012-January/325763.html
>>>
>>> You could use that and reduce the number of days to 1 (or 2 as 1 is
>>> untested :) )
>> Marco and Pieter,
>>
>> There are no DB updates required.  You should just set up MythTV such
>> that you have a Storage Group (say, Default) with one or more local
>> directories and set up your recording rules to record to that Storage
>> Group.  Have another Storage Group (say, Archived) which contains only
>> your NFS-mounted directories and do not ever choose that Storage Group
>> for any recording rules.
>>
>> Whenever you desire, simply move a recording to one of the directories
>> in the Archived Storage Group.  There is no need to change anything in
>> the database (and, really, there's no benefit to doing so--only a danger
>> of breaking something).  MythTV will still find the file, because
>> Storage Groups were designed  to allow any local movement of recordings
>> (within directories of a single Storage Group or even between Storage
>> Groups with no overlapping directories).
> And the move could simply be done via a UserJob, which is run after the
> Commercial Flagging.
> Something like,
>
> mv %DIR%/%FILE% /pathto/new/location

True, but as a point of note, I would /always/ recommend a trailing 
slash on that new location.

With Storage Groups, you should /never/ place a mount-point directory in 
the directory list.  So, if you have a file system mounted at:

/mount/point

Rather than adding the directory /mount/point to a Storage Group, you 
would put a subdirectory on the file system you're mounted into a 
Storage Group:

/mount/point/subdirectory

That way, if the file system fails to mount, there will not be a 
/mount/point/subdirectory directory, so MythTV will ignore it.  All good 
and well at this point.

If, however, you use a command:

mv %DIR%/%FILE% /mount/point/subdirectory

and the file system is not mounted at /mount/point, the /mount/point 
directory is actually a directory on the parent file system--likely 
empty.  So, the move command will actually create a new file called 
"subdirectory" in the /mount/point directory on the parent file system.  
When it runs, again, for the 2nd recording, it will overwrite the 
"subdirectory" file with the new recording.  When you finally reboot and 
the file system mounts properly on /mount/point, you've "hidden" the 
"subdirectory" file, but you have a ton of missing recordings.

If, instead, you use the command:

mv %DIR%/%FILE% /mount/point/subdirectory/

(with trailing slash) and the file system failed to mount at 
/mount/point, then we've specified that we're attempting to move a file 
to an existing directory and the mv command will error:

mv: cannot move `/path/to/recording/file.mpg' to 
`/mount/point/subdirectory/': No such file or directory

and prevent me from losing a bunch of recordings.  Granted, I could run 
across the issue of the local file system filling up and MythTV may 
start expiring recordings from it, but at least at that point, it's 
expiring them based on my expiration settings (priority or whatever) and 
it's deleting the metadata from the database and setting them to allow 
re-record--rather than just creating a bunch of orphans that I'll have 
to clean up myself.

Not that I've ever done this type of thing with a mv command by 
accident, mind you.  Just a thought experiment.  Yeah...

Mike


More information about the mythtv-users mailing list