[mythtv-users] Seek problems with Handbrake 0.9.5 high profile encodings

[Jeremy Jones]

On Tue, Jan 31, 2012 at 11:59 AM, Jason Gillis <spuppet at comcast.net> wrote:
>
> On Jan 25, 2012, at 2:08 PM, Jason Gillis wrote:
>
> Hi all,
>
> I'm having trouble with seeking in encodings of videos that have been
> created using Handbrake 0.9.5 and the "High Profile" preset.  I don't have
> problems with recordings (HD-PVR and HDHR), ISOs, or other video files.
>  This seems to have been discussed before on the list, but it doesn't look
> like it was completely resolved.  The previous discussion is here:
>  http://www.gossamer-threads.com/lists/mythtv/users/483209
>
> On my system, seeking forward always seems to work fine, but seeking back
> will go back differing amounts.  The amount it goes back seems to be somehow
> dependent on how long it's been since a seek back event occurred.  That is,
> it's fairly accurate when I've seeked back recently (i.e. I seek back once,
> it takes me a long distance back in the recording, the next seek takes me
> back about the 5 seconds I expect).  If no seek back has happened recently,
> when I seek back it can go 10 - 15 minutes back.
>
> The old thread seems indicate that some people saw relief upgrading to 0.24,
> but since I'm already on that, I'm not sure where to look next.  I don't
> recall this being a problem until relatively recently, but I don't know
> exactly when it started.  Probably in the November/December timeframe.  I've
> tried rebuilding the seek tables using mythcommflag, but that doesn't seem
> to have helped either.
>
>
> I've been experimenting with different encoding options in Handbrake to see
> what options change this behavior (and I'm finally seeing the real benefit
> of an i7! :).  It seems like nothing I do for an .m4v file type seems to
> help.  Choosing the normal or high profile doesn't seem to make much
> difference.  (Normal might result in less drift from real time, though.)
>
> I did find today that an MKV container instead of a .m4v results in no
> drift.  I also don't see any messages in the -v playback logs about video
> getting ahead of the audio.
>
> Is there anyone out there that could confirm this behavior, or perhaps
> confirm that there might be issues with processing of .m4v files? (I'm
> assuming ffmpeg handles that, so I'll do some searching about that.)
>
> J
>

If this is a recording that was already in the database (recorded
using mythtv) then you need to re-build the seek tables after running
handbrake to transcode.

See:
http://www.mythtv.org/wiki/Repairing_the_Seektable

The line: mythcommflag --file <filepath> --rebuild
should do the trick.

If this is a new video file, just being dropped into mythvideos, then
I'm afraid my answer may be irrelevant, and I can't help.

Good luck,
Jeremy