[mythtv-users] Problems with rebuilt seek table

[Christopher Meredith]

On Mon, Jul 12, 2010 at 2:18 AM, John Pilkington <J.Pilk at tesco.net> wrote:
> On 12/07/10 07:41, Rob Verduijn wrote:
>>
>> I feel your pain
>>
>> I'm currently watching tv without the use of cutlists.
>>
>> Check out :
>>
>> http://svn.mythtv.org/trac/ticket/7978
>> and possibly,
>> http://svn.mythtv.org/trac/ticket/5963
>>
>> It looks like they are intending to fix this with the 0.24 release.
>> Until then you could try these tricks, although they no longer work for me
>> :(
>>
>> Try cleaning up your db with the maintenance scripts.
>> * flush_deleted_recgroup.pl
>> * myth.find_orphans.pl
>> * optimize_mythdb.pl
>>
>> Or
>> Rebuild your seektable with 'mythcommflag --rebuild'
>>
>> Or  (adjust values for your own files)
>> mythtranscode --mpeg2 --buildindex --showprogress --chanid 1014
>> --starttime 20100609234500
>>
>> If you find any other tricks let me know.....I hate watching
>> recordings without cutlists
>>
>> Rob
>>
>> 2010/7/12 Christopher Meredith<chmeredith at gmail.com>:
>>>
>>> I've been using a script which converts HD-PVR recordings to mpeg2/ac3
>>> then rebuilds the seektable so I can take advantage of Myth features
>>> such as transcoding with cutlists and such. It has been working fine
>>> but has become one of the casualties of a recent update to current
>>> trunk. Here's what I do:
>>>
>>> Convert the recording with this command:
>>> ffmpeg -i input.mpg -vcodec mpeg2video -pix_fmt yuv420p -threads 4
>>> -qscale 1 -b 19000k -acodec ac3 -ab 192k -ac 2 -async 1 -y -f vob
>>> output.mpg
>>>
>>> Then I move output.mpg to input.mpg and run this:
>>> mythtranscode --mpeg2 --buildindex --allkeys --showprogress --infile
>>> input.mpg
>>>
>
> I'm not sure what --allkeys is supposed to do in this context.  I suppose
> that in a 'proper' transcode it produces a file that is entirely composed of
> I frames (ie it treats every frame independently so that the result is
> larger than a normally coded mpeg2 file but can be more accurately edited),
> but here you are just cataloguing the existing keyframes.  What happens if
> you leave it out?  And IIRC there's sometimes a difference between the
> --infile treatment and the --chanid --starttime treatment.  HTH.
>
> John P

Turns out the solution was to use --chanid and --starttime instead of
--infile. I looked more carefully at the output from the --infile
method and noticed a message saying that the recording with the
specified filename could not be found, but the process ran anyway. I
guess there's currently a problem with the interaction between myth
programs and the database. This may be why mythtranscode can't find
recordings in the db even when given the right name and why
transcoding with cutlists is broken. Come to think of it, this may
also explain the weird mythweb behavior we're seeing in trunk.