[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:
>>> 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:
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
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...
More information about the mythtv-users