[mythtv-users] Slow MySQL query after delete

Michael Rice mikerice1969 at gmail.com
Thu Nov 29 21:52:52 UTC 2007


On 11/29/07, David Brodbeck <gull at gull.us> wrote:
>
> On Nov 29, 2007, at 10:21 AM, Michael Rice wrote:
> > In most cases (at least for me) I don't think deleting a recording
> > needs to invoke an immediate reschedule.  Maybe a "Delete Later" or
> > "Delete But Don't Reschedule" option would be a good thing.
>
> Normally everything on my system is set to auto-expire, so if the
> scheduler decides a program needs more space, it just kills off a few
> old recordings anyway.  There isn't any situation where deleting a
> file manually will make a recording possible that wasn't possible
> before.

If you are talking about deleting a recording (and not the file)
that's actually not true.  If you have a rule with "keep at most X
episodes" and delete one you'll then have X-1 and a reschedule would
be needed for the Xth episode to record.

There are likely other ways as well.  I think you can match duplicates
based on what is currently "recorded".  Once you delete something and
it goes into "oldrecorded" a show might then be able to record.

In any case for me these rules/issues are not too important.  If I
delete a Sponge Bob I can wait until the next normal reschedule and if
I miss a few no big deal.  I'd gladly accept that trade off rather
than sitting waiting in the UI.

Nonetheless that "blocking behavior" in the UI is what is bad.  Can
anyone (a dev?) explain why it does this?

A reschedule later (or don't reschedule) option might improve the
situation but it really only treats the symptom.  All reschedules do
not block the UI so why does this one?  Would it be possible to queue
the reschedule instead of waiting for it to finish?


More information about the mythtv-users mailing list