[mythtv-users] mythcommflag vs mythtranscode for videos

[HP-mini]

On Tue, 2013-01-29 at 14:22 -0800, Jim Stichnoth wrote:
> On Tue, Jan 29, 2013 at 7:54 AM, Dave Hill <myth at davidrhill.com> wrote:
> >
> > On 1/7/2013 10:33 AM, Dave Hill wrote:
> >>
> >> On 1/4/2013 1:39 PM, Jim Stichnoth wrote:
> >>>
> >>> On Fri, Jan 4, 2013 at 7:49 AM, Dave Hill <myth at davidrhill.com> wrote:
> >>>>
> >>>> Hello,
> >>>> Running mythbuntu 12.04 / mythtv 0.26, I have been finding that
> >>>> mythcommflag
> >>>> --rebuild --video does not seem to be updating the filemarkup table.
> >
> >
> > Could someone enlighten me as to the difference between these two commands?
> > - mythcommflag --rebuild --video <relative path>/<filename>
> > - mythtranscode  --buildindex --video --infile
> >
> >
> > I'm running 2:0.26.0+fixes.20130126.14aa707-0ubuntu0mythbuntu1 and I have
> > lately been seeing issues seeking and/or saving bookmarks with SOME of these
> > files that had their seek tables built with mythtranscode.  The behavior I'm
> > seeing is consistent with http://code.mythtv.org/trac/ticket/11308 -- that
> > suggests running mythcommflag on the files in question. This appears to work
> > to resolve the seeking issues.
> >
> > I've also found that videos that had their seek tables built with
> > mythtranscode (the ones that work) seem to seek "choppily" -- ie when I Jump
> > Ahead, the picture is very pixelated for a second or two -- where if they
> > were processed with mythcommflag, the seeking works fine.
> >
> > Any information about how this works would be appreciated but I guess my
> > main question is -- is mythcommflag doing its work in a different db table?
> > Is there some way I can verify that a seek table was generated after the
> > mythcommflag --rebuild operation?
> 
> All three tools (the recorder, mythcommflag --rebuild, and
> mythtranscode --buildindex) produce seektables in the same place,
> namely the recordedseek table for recordings and the filemarkup table
> for videos.  If mythcommflag is not producing any seektable entries,
> one possibility is that the underlying ffmpeg is crashing on the file,
> which is not unheard of.  You might be able to detect this by running
> it from the debugger.  If not, it would help to get access to the
> video file in question.
> 
> As for the "choppy seeks", is this from an HD-PVR recording?  There
> has been an issue where regenerating the seektable would identify
> non-IDR I-frames whereas the recorder only identifies IDR frames.
> That would likely lead to pixelation after a seek until an actual IDR
> frame is reached.  This issue was fixed in mythcommflag, but may still
> be there in mythtranscode.
> 
> Jim

On my dirty 0.26_fixes..
"mythcommflag  --rebuild --video" requires an absolute filepath.

mythcommflag removes any seektable on .mkv files in "Videos".
(No I-frames found, rewinding...)
mythtranscode creates a seektable for .mkv files & then this prevents
mythplayer working..

Fortunately .mkv files seek very well without a seektable.

Brett