[mythtv-users] Inconsistencies in generation of recordedseek table data (0.25/fixes)

[Ken Scales]

On Thu, Jun 14, 2012 at 1:32 AM, Ken Scales <ashtonprairie at gmail.com> wrote:

>  I found that the results with "mythcommflag --rebuild" had several
> problems: not only did the seek table not line up very well with the
> skiplist values, but seeking within the cutlist editor had significant
> misbehaviours, making editing a very frustrating experience.  See my note
> below regarding the seeking misbehaviours.  Based upon this experience, I
> definitely do not recommend using "mythcommflag --rebuild" for 720p ATSC
> recordings in current 0.25/fixes builds; use "mythtranscode --buildindex"
> instead.
>

< snip >


>  After running "mythcommflag --rebuild --chanid 1041 --starttime
> 20120613155900"
>    Blank frames start:  3470 (skip mark offset: -20), 31760 (-50), 62930
> (-50), 101470 (-53), 146066 (-52),
>       163220 (-42), 185810 (-47), 207152 (-52); end frame 222799
>
> However, seeking within the cutlist editor exhibited odd behaviour: e.g.,
> attempting to move to the next cut point would only move 1 frame at a time
> forward or backward, until the cut point was finally found, and then would
> do the expected skip to the next cut point. Similarly, once the above
> "first" blank frame had been located, attempting to move by a single frame
> backward would result in an unexpected jump of several frames back:
>
>    Moving 1 frame back skips: 3470->3463 (7 frames), 31760->31747 (13),
> 62930->62926 (4), 101470->101458 (12), 146066->146053 (13),
>       163220->163216 (4), 185810->185806 (4), 207152->207142 (10)
>
>
>
Update/correction:  I've now seen this same misbehaviour in the cutlist
editor after rebuilding the seek table for another recording with
"mythtranscode --buildindex", so this is NOT related to the seek table
values generated by "mythcommflag --rebuild".  In retrospect, this actually
makes sense that it would be a separate issue in the cutlist editor (and
perhaps may be addressed by some of the recent ffmpeg-related updates in
0.26).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120615/ea0ec897/attachment.html>