[mythtv-users] Slow MySQL query after delete

[Ryan Steffes]

On 9/4/07, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> On 09/04/2007 11:31 AM, Victor Perez wrote:
> > <rant>
> > I've been waiting for somebody to fix these issues for a while. My
> > remote frontend hangs and I have to kill it every time I delete
> > something. Now that I compiled from the sources to get the SD patches
> > I think I finally gonna get my hands dirty and fix with this whole
> > database mess the developers got into.
> > </rant>
>
> Unless you're planning on forking Myth, you should probably discuss your
> ideas for fixing "this whole database mess".  There are some solid ideas
> on where we're going with MythTV and databases.
>
> The high-level overview is that we're going to move to an embedded MySQL
> (if the users don't see a DB, they can't complain about it) that can be
> configured and optimized automatically and have a "mythdata" server-type
> program that provides all access to the data so clients do not need to
> use SQL.
>


This is a bit of an aside, and I admit to not keeping up with this
sort of thing as well as maybe I ought, but I'm a bit curious about
whether embedding the DB prevent me from doing the forcible
maintenance I do from the mysql command line because it's so much
faster than going through the tedious front end tools available.
Assuming that comes to pass, will that make it impossible to directly
access the DB to force updates for things like the jobqueue (I've got
multiple not particularly stable backends, I get hung jobs a lot due
to dualbooting) and MythVideo.

As an example of what I'm talking about, this query is run pretty
often as I rip TV on DVD collections and add dozens of shows at a time
to my MythVideo to flag all the shows as browseable and TV shows:

update videometadata set browse=1,category = 2 where filename like
"/home/MythVideo/tv/%";

I'd be sad to see that sort of thing be unavailable.

Ry