[mythtv-users] Mythtranscode & database updates

[John Pilkington]

mythtv at notleyc.fastmail.fm wrote:
> 
> On Tue, 10 Nov 2009 15:45 +0000, "John Pilkington" <J.Pilk at tesco.net>
> wrote:
>> mythtv at notleyc.fastmail.fm wrote:
>>> I've had a scan through the archives and haven't found a definitive
>>> answer to this - apologies in advance if I've missed an answer...
>>>
>>> I'm running the release candidate of MythTV 0.22 on Ubuntu Karmic Koala
>>> and want to script a job that runs each night and automatically strips
>>> out commercials.  I've built a Perl script that looks in the mythconverg
>>> database and builds a list of all recorded files that have a cutlist and
>>> have not yet been transcoded.  This part works exactly as intended and
>>> for those files that match, I'm constructing the following command:
>>>
>>> /usr/bin/mythtranscode --mpeg --honorcutlist --chanid
>>> {PULLED-FROM-MYSQL} --starttime {PULLED-FROM-MYSQL}
>>>
>>> At present I'm manually running the commands and they appear to be
>>> completing successfully; however I'd assumed/hoped that the
>>> mythtranscode command would update the 'recorded' table to reference the
>>> new file.  It seems that it's just creating a new file with '.tmp'
>>> appended to the filename and then leaving the existing file in place.
>>>
>>> I guess I can achieve this myself by getting my script to remove the
>>> original file and rename the newly created .tmp file; however I wanted
>>> to make sure I wasn't missing something before I proceed...
>>>
>>> Cheers in advance for any help,
>>> Chris
>> When Mythtranscode completes it usually renames its input file to .old, 
>> or deletes it if that option has been set in mythtvsetup, and renames 
>> the .tmp output so that it replaces the input.  But for some 0.22 series 
>> builds this sequence doesn't complete - see
>>
>> http://svn.mythtv.org/trac/ticket/7315
> 
> One other thing I forgot to add was that apart from the file being
> renamed, the other thing I'd expected was that the recorded table would
> be updated to indicate the recording had been transcoded; however this
> is not happening either.  I guess it could be part of the same problem
> John mentions, but again, if I'm wrong to expect the file to be marked
> as transcoded, I'd appreciate it if anyone could let me know.
> 
> Cheers again,
> Chris

As far as I know, when it's working the new file just takes the place of 
the old one: preview and file size in the database are updated - 
although you may need to force a refresh by going back a step in the 
menu - and you can go round the loop as many times as you like.

John P