[mythtv-users] REPAIR/OPTIMIZE in HouseKeeper (was Re: Running optimize_mythdb.pl before mythfilldatabase)

[Michael T. Dean]

On 02/22/2007 05:31 PM, f-myth-users at media.mit.edu wrote:
>     > Date: Thu, 22 Feb 2007 11:52:23 -0500
>     > From: "Michael T. Dean" <mtdean at thirdcontact.com>
>
>     > On 02/19/2007 10:27 PM, Michael T. Dean wrote:
>     > > I'm also considering asking Chris Pinkham if he'd be interested in a 
>     > > patch that puts the REPAIR and OPTIMIZE in the housekeeper.
>
>     > Looking deeper in this, I'm starting to think this may not be a good idea...
>
> I agree with you that it's not a good idea, and for an entirely
> different set of reasons as well.  Here's what I wrote a couple
> of days ago, then held off to see if anyone else had some opinions:
>
> No!  Please no!
>
> Unless you can guarantee that the housekeeper will -never- be running
> while a recording is in progress (or several minutes beforehand!),
> please do NOT add things that lock tables for extended periods of time
> and run when the user can't control them.
>   

I'm working with Chris Pinkham on that right now.  We have an initial 
plan, and I'm considering making some adjustments.  (Probably should 
have mentioned that to Chris before saying so here, though...)  It'll 
probably be a couple of weeks before I have the patch (travel for work 
is getting in the way of my Myth time).

> Otherwise, you WILL trash recordings in progress from anything that
> must write to recordedmarkup/recordedseek, at least until the current
> issue of interaction between seek inserts & buffer-reading is resolved.
> [And remember that, by default in recent releases, mfdb runs at
> -random- times chosen by DataDirect, not by the user, hence the user
> never knows when a repair/optimize will lock a table and glitch a
> recording.]
>   

But housekeeping isn't just running mythfilldatabase.  DailyCleanup is 
much more consistent about its execution time.

> (*) E.g., because pretty much every time somebody says anything at all
> DB-related, you (mtdean) come back with "have you repaired & optimized?"
>   

Yes.  Which is why I was considering putting it in daily cleanup.  But, 
I no longer plan to do so.

However, regarding the not-running during recordings, the approach we're 
taking is to allow a job to specify whether to run anyway (i.e. if 
recordings taking place during the job window will prevent the job from 
running that day due to a requested lead-time constraint).  The 
mythfilldatabase execution will be set to run anyway (because missing it 
could cause missed/incorrect recordings, which is probably more annoying 
to users than recording glitches).  However, daily cleanup will not be 
run anyway (we can always "catch up" on it tomorrow).

So, this is the one benefit to adding another "daily" script to run.  It 
could be set up to run as part of daily cleanup (and /not/ ignore the 
specified "lead time"--as doing a daily repair/optimize isn't critical), 
while mfdb can be executed during a recording if absolutely necessary.

I don't have any personal reason to choose one approach or the other, so 
I'll leave it up to the devs whether an extra script to configure is 
worth the benefit (to possibly only a small number of users)--especially 
since that benefit can be achieved through careful selection of cron job 
execution time or even through some fancy scriptwork.

Mike

[OT]:

/me wonders if you would still have the "trashed recordings" issue with 
a more current version of Myth (like 0.20-fixes or even 0.19-fixes)...

Only wondering because I don't have these issues with 4x pcHDTV 
HD-3000's (often all four are recording simultaneously), MySQL server 
running on the master backend, non-RAID'ed PATA disks; and 
mythfilldatabase--and even optimize_mythdb.pl--run during recordings 
sometimes.  Note that I'm not saying you should upgrade as I don't know 
whether there is a difference that would help you.  Another system I 
manage has 4x PVR-250's, combined frontend/backend, with MySQL server 
(and Apache httpd and ProFTPd and TeamSpeak server and a bunch of other 
junk), non-RAID'ed PATA disks, and haven't had any recording issues with 
it, either.  (I used to use LVM on the SDTV system, but don't, anymore.)