[mythtv-users] 0.19 SQL tables accumulating too much data?
Michael T. Dean
mtdean at thirdcontact.com
Thu Aug 3 02:02:21 UTC 2006
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.
> 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.
(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
More information about the mythtv-users