[mythtv-users] recordedseek table content

[Raymond Wagner]

On 12/12/2010 15:14, D. R. Newman wrote:
>>> Also, when restarting MythTV (e.g. after a crash), it is worth deleting
>>> currently running jobs (status = 4) from the jobqueue, otherwise a
>>> duplicate job will be started.
>> Actually, you're better off killing the running job on the system and
>> letting MythTV restart the job--so that it can manage the job in the
>> queue.  Otherwise, you'll end up having MythTV start the next job(s) in
>> the queue without knowing that a job is already running, so your max
>> jobs setting isn't respected.
> That is what I do if the job has just started. But if the job is already
> in Avidemux's 2nd pass of a conversion to Xvid or MPEG4, a restart
> repeats hours of conversion.

The only reason to ever do a multi-pass encode is if you're trying to 
fit an exact file size.  Otherwise, just set a quantizer for an 
acceptable quality, and let the codec do its thing.

>> If there's any situation that /requires/ direct DB editing, please
>> submit patches so that we can fix MythTV to actually do whatever you
>> feel is so important that you're editing raw data without any data
>> integrity checking.
> Well, having converted the video to a more compressed format, I store it
> in the mythvideo directories, add its name to the videometadata table,
> delete the file from the TV directory and remove the entry from the
> recorded table. But that isn't a patch, I could possibly turn it into a
> user contributed script after some more testing.

See http://mythtv.org/wiki/Mythvidexport.py
It already does most of those operations as a user job, plus allows user 
defined formatting of the resultant filename, and metadata pulling from 
the defined data grabbers in MythVideo.  Also, you should _never_ mess 
with the recording files or recorded table.  Tell the backend to delete 
the program, and let it clean up properly.
http://mythtv.org/wiki/DELETE_RECORDING_%28Myth_Protocol%29