[mythtv-users] Weird/Blocky Transition Effects - SOLVED

[Ken Bass]

Ken Bass wrote:
> When I fast forward a recorded program, I get a very blocky transition 
> effect. mythtv did not used to do this and I'm not exactly sure when it 
> started. Sometimes I notced the 'end time' of the program when skipping 
> fluctuates.
> 
> Has there been a change related to the skip logic or anything related to 
> skipping on a frame boundary (MPEG GOP)?
> 
> *OR*
> 
> Is this related to the corrupted recordedmarkup table? I let mysql 
> repair it but is this a consequence of whatever data was corrupted?
> Is there anyway to regenerate this? 

It turns out it is related to the mysql recorded markup table being 
corrupted.

I found a few side effects to this:

1) Thumbnails did not generated for files without a seek table! This 
meant thumbnails did not show up in mythweb either. This also caused 
mythweb to display the 'Recorded Programs' very very slow. Each time I 
visited that page, it would tell the backend to try to grab a frame and 
the backend would complain as follows for each file:

2005-11-06 19:25:32.986 Could not open 
/mnt/store//1011_20051104160000_20051104170000.nuv.png.  0 retries 
remaining.
2005-11-06 19:25:33.754 Not enough video to make thumbnail

I've saw lots of thumbnail complaints in the archive, perhaps some are 
created by a corrupted recordedmarkup table. (Other problems could be 
wrong permissions on the image_cache directory or missing video_dir symlink)

In NuppelVideoPlayer.cpp - if the GetScreenGrab() method fails it causes 
this 'Not enough video to make thumbnail' error. There is a check for 
'hasFullPositionMap' which appears to be derived from the recordedmarkup
table when playing back.

2) I repaired the recorded markup table using the commands:
'mysqlcheck -r -u mythtv -pmythtv mythconverg'

3) Running 'mythcommflag --rebuild' regenerates the seek table (GOP 
based) (Add --all argument if you need to do all files versus just those 
not present in the recordedmarkup table)

4) Running 'mythcommflag --hogcpu' regenerates the commercial flag data. 
(Add --all argument if you need to do all files versus just those not 
present in the recordedmarkup table)

After the above commands, thumbnails generated properly, skipping to 
longer was blocky, the ending time shown when skipping is 
accurate/stable, and commercials are reflagged.

It seems that if I skipped step #3, the commercial flagging dumped a lot 
of errors about 'missing frames', 'motion type errors', 'ac-tex' errors 
and the like.

Bottom line: The recorded markup table is the largest table in the 
database related to mythtv. When machine lockups occur and you need to 
hard power cycle it is one of the most likely databases to be corrupted. 
Its very important for proper skipping and thumbnail generation. Simply 
repairing the mysql is not necessarily enough.