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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
