[mythtv-users] mythcommflag vs mythtranscode for videos

[Peter Bennett (cats22)]

On 01/29/2013 10:54 AM, Dave Hill 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?
>
> Thanks very much,
> Dave Hill
>
I am using mythcommflag and it seems that it actually deletes the seek
table, i.e. existing seek table is removed. This actually works quite
well, the transcoded file is an X264 mks file and seeking works
perfectly with no seek table. However if I do not run the mythcommflag,
the old seek table is still there, and seeking does not work at all,
trying to go forward or back stays in the same place and pixellates the
screen.

I am not sure why this is so, but it works for me. I thin perhaps x264
mks files do not need a seek table so the mythcommflag is removing it.

Peter