[mythtv-users] mythcommflag vs mythtranscode for videos

[Jim Stichnoth]

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 <path>/<filename>
>
> I thought I had read somewhere that they were equivalent, but I continue to
> see that mythcommflag doesn't seem to update the filemarkup table with any
> entries containing the filename in question.  After running it, I have
> dumped out the entire table grepping for the base filename and found 0
> entries.  However, after running mythtranscode, I see 500+ entries in the
> filemarkup table for the file that was processed.
>
> 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