[mythtv-users] Slow MySQL query after delete

[Michael T. Dean]

On 09/05/2007 05:06 PM, Ryan Steffes wrote:
> On 9/4/07, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>   
>> 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.

I guess we'll find out when someone makes the time to move Myth to
embedded MySQL.

However, and I'll admit to being a starry-eyed dreamer, here, ideally,
any effort that a user goes to to work around the UI would be better
spent on helping to improve the UI.  Since we currently have the
SQL-catch-all fixes available for things like you've described, there's
little motivation to write tools/support to improve the UI experience
for the user.  Perhaps if access to the data becomes a little less
convenient, it will encourage more UI-fixing work.  :)

Mike