[mythtv-users] Struggling with MythArchive

[John Pilkington]

On 04/01/13 22:10, John Pilkington wrote:
> On 04/01/13 14:42, Alan Chandler wrote:
>> On 03/01/13 22:21, Paul Harrison wrote:
>>>
>>> If all goes well you should be left with a final.vob that can be
>>> passed to dvdauthor to create a DVD.
>>>
>>> Paul H.
>>
>> Thank you for your, and John's hard work on this.  I'm tied up with
>> other things for a couple of days, but I have flagged the post to come
>> back to it towards the backend of the weekend to see if I can at least
>> manually create the dvd.
>>
>
> While this topic is being aired I'll add a little more.
>
> I don't expect to make a habit of creating DVDs from h264 HD recordings,
> because it's much quicker to start from an SD DVB-T mpeg2 recording and
> the final bit rates have not been wildly dissimilar; but it is still
> seems useful to be able to do it.
>
> I've made a few with commercials removed.  For that I used Mythpycutter
> [1] followed by the mythffmpeg command line from earlier in this thread,
> and then by a mythcommflag --rebuild.  That effectively gets me to the
> familiar SD-recording input.
>
> Although the cut HD recordings play quite well the output from the
> re-encoding showed A/V sync shifts after each cut; but on passing
> through a Project-X demux/remux (outside or within MythArchive) that
> drift has been corrected and the final DVD has been fine.  I suspect
> that without Project-X that wouldn't be true.
>
> I haven't tried the other approach of cutting after re-encoding to
> mpeg2.  It may work well, but I don't know how robust the re-encoding
> would be when asked to work through commercials and programme
> changeovers.  With SD recordings I eventually made a complete switch to
> using Project-X to do cutting and error correction outside MythArchive,
> and I now have almost no failures or A/V problems.  And, using mythlink
> output sorted by title or filesize, I can make reasonably well informed
> decisions on how to fill the space on a DVD.
>
> HTH
>
> John P
>
>
> [1] http://www.mythtv.org/wiki/Mythpycutter
>
> The version as posted needs editing to provide directory info and the
> variables for DB access that were formerly read from mysql.txt

Another comment, for completeness.  I would still see occasional 
failures like the one mentioned here:

http://code.mythtv.org/trac/ticket/8376#comment:9

if I didn't have this set to be a nonfatal error at about line #1625 in 
mythburn.py     I think it's a rare corner-case in mplex, so not a real 
mythtv bug.  It's not caught if fifos are enabled, but that prevents use 
of the shrink-to-fit requantiser.