[mythtv-users] recordedseek table content
raymond at wagnerrp.com
Sun Dec 12 21:08:42 UTC 2010
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.
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.
More information about the mythtv-users