[mythtv-users] Puzzled by seektables.

[Michael T. Dean]

On 10/28/06 08:35, Davide Chiarini wrote:

>>I'm guessing either a) you have a 0.19 version of
>>mythbackend/mythcommflag on your system, b) your recordedmarkup table
>>was corrupt when you upgraded to 0.20, so data wasn't properly moved to
>>recordedseek, or c) your recordedseek table is currently corrupt (does
>>not rule out b, though).
>>    
>>
>i'm sure that both programs are version 0.20. i've checked out both
>recorededmarkup and recordedseek tables, and both contain data, and
>are pretty heavy (135k records the first, 300k the second)
>  
>
That's a sure-fire indication you've got some 0.19 stuff (data and/or 
programs) hanging out.  In 0.19 and below, the MPEG-2 "seektable" was 
stored in the recordedmarkup table.  This seektable requires on the 
order of 1 record per 1/2 second of MPEG-2 recording.  Therefore, when 
using MPEG-2, it makes a /lot/ of records.

In 0.20, the seektable was moved out of recordedmarkup to its own (new) 
table, recordedseek.  The migration is done automatically during upgrade 
(unless a corrupted database prevents it).  Therefore, if working 
properly, your recordedmarkup table should be small (containing on the 
order of 2 records per flagged commercial break and/or 1 record per cut 
point), but the recodedseek table should be large.

On my system, I have 304 recordings (all but 3 are MPEG-2):

mysql> select count(*) from recorded;
+----------+
| count(*) |
+----------+
|      304 |
+----------+
1 row in set (0.00 sec)

When I look at recordedseek, I have:

mysql> select count(*) from recordedseek;
+----------+
| count(*) |
+----------+
|  2197930 |
+----------+
1 row in set (0.00 sec)

However, notice recordedmarkup:

mysql> select count(*) from recordedmarkup;
+----------+
| count(*) |
+----------+
|     5265 |
+----------+
1 row in set (0.00 sec)

Oh, and in case I haven't implied it, yet, I'll say it explicitly:  my 
database/MythTV system is in proper working order.  ;)

So, I can guess you have significantly less total recorded material (by 
time, at least) than I, but your recordedmarkup is significantly larger 
than mine, meaning you have seektable information getting in there.

>>The first step in fixing it is to run optimize_mythdb.pl from the
>>contrib directory of the source distribution (also probably installed by
>>packages).  Once that's done, run "mythcommflag --rebuild -f
>>/path/to/recording" on one file.  Then, try to edit that recording (let
>>me know if you need help figuring out which recording goes with a file,
>>but basically, the last part of the filename is date/time and the first
>>part is typically "related" to channel number).
>>    
>>
>optimize_mythdb.pl seems to have worked fine. I run mythcommflag
>(below is the output), and it went through the whole file (although
>there's a " Parser not found for Codec Id: 94211" message).
>Unfortunately I still can't edit the recordings, and I still get the
>"no seektable" error.
>
>In mythbackend logs I get
>2006-10-28 05:17:07.629 Cannot edit - no full position map
>
>Is there maybe a way to reconstruct the table (would I lose my
>recordings if I drop it?)
>

Which makes me think that the mythcommflag you're running from the 
command line is a 0.19 one...  Check carefully for multiple 
"mythcommflag" programs on your system.  Perhaps you have a packaged 
version in /usr and a compiled-yourself version in /usr/local?

Once you fix the install (perhaps uninstalling everything Myth (but not 
MySQL or the database) would be a good start), you might want to do a:

TRUNCATE TABLE recordedmarkup;
(otherwise, you'll have orphaned seektable information in this table 
probably forever)

then, optionally:
TRUNCATE TABLE recordedseek;
mythcommflag --rebuild --all

then:
mythcommflag --all

You don't need to TRUNCATE the recordedseek table, so this would be a 
"because I want to start over and ensure it's good data now that my 
system is properly installed/configured".

The first mythcommflag (with --rebuild) will take a while (maybe a day 
with your recordings).  The second will take much longer (perhaps 4 
days), and new recordings won't be commercial flagged when it's 
running.  If you don't plan to use the automatically-detected commercial 
break start/ending (on previously-recorded shows) but plan to create 
your own cutlists with the editor, you could skip the "mythcommflag 
--all", too. 

Mike