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

Michael Watson michael at thewatsonfamily.id.au
Sat Feb 11 01:32:51 UTC 2012


On 11/02/2012 9:13 AM, Michael T. Dean wrote:
> 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
> _______________________________________________
>

Point taken.   Whilst we are being picky, it would be a good idea to 
check if the file is going to actually fit on the destination device 
before attempting to move it, and add an ionice to the mv command, so as 
to not max out the io bandwidth for myth recording operations..

Michael



More information about the mythtv-users mailing list