[mythtv-users] mythcommflag vs mythtranscode for videos

[Dave Hill]

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