[mythtv-users] possible bug in 0.28 mythtranscode

[John Pilkington]

On 06/08/16 23:35, Mark Perkins wrote:
>> On 7 August 2016 1:41:52 AM ACST, John Pilkington <J.Pilk at tesco.net> wrote:
>>> On 06/08/16 16:44, Jim Abernathy wrote:
>>>> On 08/06/2016 09:44 AM, Mark Perkins wrote:
>>>> In 0.28 there is a tickbox in mythtv-setup / 1. General / Job Queue
>>>> (global) about page 9 or so "save original files after transcoding".
>>>> Does mythtranscode honor this switch if mythtranscode is called from
>>>> an external script? If my test 0.28 backend is correct the tickbox
>>>> defaults to unticked, ie original files are not saved. So this might
>>>> be the issue / fix.
>>> So after I ticked the option in mythtv-setup and I ran the same test
>>> with external mythtranscode with the -o option.
>>>
>>> I see that original file is gone alone with it's .png.  However, I
>> see a
>>> .ts.old version of that recording. when I run mythfrontend it can't
>> find
>>> the program even though it's listed.
>>>
>>> If I rename the .ts.old back to .ts, mythfrontend can now find and
>> play
>>> the recording, but there are no commercials detected and no cutlist.
>>>
>>> The -o file is created correctly with the cutlist honored.
>>>
>>> The version is mythtranscode version: fixes/0.28 [v0.28-46-ge5ce273]
>>>
>>> Per the console log below I see it's having problems renaming a
>> .ts.tmp
>>> version of the file back to a .ts.  Not sure if it means .ts.old or
>> what???
>>
>> I think that would be the default output file, but in your case its
>> name
>> has been specified by the -o option; so xxxx.ts.tmp doesn't exist.  It
>> can't be renamed and myth can't see it.
>>
>> xxxx.ts.old is the file used as input, which was renamed from xxx.ts at
>>
>> the start of the process.
>
> Ok, well it seems like a bug to me then. Mythtranscode is throwing an error because the xxxx.ts.old file is missing. My read of it is that the use case of the -o switch was missed when the cleanup changes were made. Hopefully one of the devs will pick it up from the tickets and look into it / confirm.

I think it's xxxx.ts.tmp that's missing :-)  xxxx.ts.old does appear to 
follow the setup flag.

It does look as if the behaviour changed, but was it ideal?  Using the 
-o option should probably end up by moving xxxx.ts.old and its seektable 
back to xxxx.ts, but what about its cutlist etc?  Restore or clear? 
See the copy_and_transcode script writeup.

The Ticket ought to have a link to this thread.