[mythtv-users] Slow MySQL query after delete

[Michael Rice]

On Dec 4, 2007 10:42 PM, Chris Pinkham <cpinkham at bc2va.org> wrote:
> * On Wed Dec 05, 2007 at 12:16:45AM -0500, Michael T. Dean wrote:
> > 2007-12-04 22:00:08.327 scheduler: Scheduled items: Scheduled 265 items
> > in 2.8 = 0.00 match + 2.79 place
>
> It probably doesn't affect you much, but tonight I found an issue
> in the interaction between the delete code on the frontend and the
> scheduler on the backend.  In current SVN, with the new Watch List,
> we update the 'last_delete' field in the record table whenever we
> delete a recording.  This is done on the frontend before it tells
> the backend to delete the recording.  This update hangs if the
> scheduler is currently running because the scheduler has an implicit
> read-only lock on the record table.  So, for people who have long
> scheduler runs, if they try to delete a recording while the
> scheduler is running, they will experience a hang on the frontend
> until the scheduler's BUQ is finished.
>
> I'm sure you saw it, but for other's reading this thread, I did
> commit a patch tonight which will eliminate the reload of the complete
> recording list every time you delete a recording.  This was happening
> twice for every recording deleted (unless you did them fairly close
> together and have slow deletes turned off).  With the current code,
> the frontend will delete the recording's info from its in-memory
> program cache rather than reloading the complete list from the
> backend.  This applies whenever a recording is deleted, whether it
> is manual by the user or by the autoexpirer or by another user on
> another frontend.
>
> http://svn.mythtv.org/trac/changeset/15059

I highly recommend applying this patch if you have a long running BUSQ
and are running SVN.  It has been over a week since I applied it and
neither my wife nor I can recall having to hit the "restart
mythfrontend button".  That's a huge improvement since before this
patch we'd be using it numerous times a day trying to recover our
"locked up" front end.