[mythtv-users] 0.19 SQL tables accumulating too much data?

[Michael T. Dean]

On 08/02/2006 08:08 AM, Greg Estabrooks wrote:

>>Specifically, if I have ever recorded a show in the past, then 
>>EVERY SINGLE TIME it is rebroadcast Myth adds another copy to the 
>>"previously recorded" list.  Here's a sample from the "oldrecorded" 
>>table for "Holmes on Homes":
>>
>  This came up can in January on IRC but I can't for the life of me
>remember whether it was "fixed" or if it was intentionally left that way.
>
>http://svn.mythtv.org/trac/ticket/1115
>
> Maybe Xris will see this and chime in.
>

(I'm not xris, so I hope you're willing to settle...)

MythTV records the status of all airings of shows that match recording 
rules.  Note, however, that the only "important" ones (as you see it ;) 
are those with a recstatus of -3 (rsRecorded).  All other entries in the 
oldrecorded table are "negative" entries (reasons why Myth didn't record 
the show--including rsPreviousRecording, rsEarlierShowing, 
rsLaterShowing, and more).

In storing information (both positive- and negative) about all shows 
that match the recording rules, users are able to see /why/ a show did 
not record.  The information is made available through the frontend's 
Previously Recorded screen.

The meaning of the recstatus field can be found in the file 
libs/libmythtv/programinfo.h in the enum RecStatusType.  Even better (so 
you don't have to deal with "raw" numerical values), you can use the UI 
as described above.

Note that these oldrecorded entries are cleaned out of the database by 
mythfilldatabase when they are more than CleanOldRecorded days old (this 
is a setting for which there is no UI element, so if you wanted to 
change it you would have to do so directly through the database).  The 
default value for CleanOldRecorded is 10.  Therefore, if you miss a 
recording and want to know why, you have 10 days to check the Previously 
Recorded screen to see what happened.

So, you say, "But I use EIT data, so I don't run mythfilldatabase."  
Well, time to start running it.  /All/ users of MythTV should run 
mythfilldatabase.  If your only videosources are configured with "No 
grabber" and/or "EIT only", mythfilldatabase won't "fill" your database, 
but will do all the other cleanup that needs to be done (and there's 
more cleanup than just cleaning oldrecorded).

Note that if you're using 0.19-fixes, you'll get an error message when 
you run mythfilldatabase for each videosource that's configured as EIT 
only (specifically, "Grabbing XMLTV data using eitonly is not verified 
as working").  As long as you're using 0.19-fixes r9665 or above, this 
is nothing to worry about (and mythfilldatabase will still clean up the 
database for you).  If you're using 0.19-fixes pre-r9665 or 0.19, you'll 
get the error, but mythfilldatabase will bail out before it does the 
clean up.  So, you should upgrade to the most-current 0.19-fixes 
available from your packager.  If you're using SVN trunk r10238 or 
above, you won't get an error (instead, it will say, "Source configured 
to use only the transmitted guide data. Skipping.") and mythfilldatabase 
will clean up your database for you.

If you have an early 0.19-fixes version or 0.19 and you can't upgrade, 
just wait until your next upgrade (i.e. 0.20 when released) to start 
running mythfilldatabase.  Until then, you'll continue to have the same 
issues you've been having (and, since the only one you've noticed is the 
oldrecorded table growing larger, it doesn't seem to be that much of a 
problem for you).  As soon as you upgrade to 0.20 and start running 
mythfilldatabase, it will clean up /all/ the old oldrecorded entries in 
one fell swoop.

Mike

(BTW, Chris, thanks for posting this to the -users list--as it is a 
user's list question--to verify what you're seeing is a bug before 
considering going to the -dev list.  It's refreshing to see someone do 
things right instead of "short-circuiting" the process to save himself 
time.)