[mythtv] sql code

[Andy Davidoff]

#if Matt Zimmerman /* Feb 20, 12:13 */
> I run mythfilldatabase on a diskless (NFS root) box, talking to a remote
> MySQL server, which is probably fairly close to a worst-case scenario, and
> it takes a negligible amount of time to do these inserts.  Additionally, 99%
> of the time is spent waiting for the grabber anyway.  Is there really a
> problem to be fixed here?

Not really, like I said -- it's just sub-optimal.  As long as it doesn't
impact the CPU too much, who cares about a process run in the background
in the middle of the night?

> The per-host settings stuff went in only in the past few days; I didn't
> realize that it added an extra query.  Feel free to provide a patch for
> that.

Yep.

> The SELECT NULL query is a workaround for the fact that the mysql client
> library does not recover gracefully if a TCP connection is lost (for
> example, a timeout, or a mysqld restart).  This query is a canary which will
> fail, but allow the client library to clean itself up so that the next one
> will succeed.
>
> This sucks, but it works for now.

I figured as much, but why can't we just execute the query and clean-up/
execute it again if the first try fails?

> Caching these settings would be easy; feel free to provide a patch.
> However, I doubt this is truly the source of your slowdown, on my system
> (which I described above), mythfrontend starts in 2-3 seconds.
#endif /* mdz at debian.org */

I'm not at the point where I can start mythfrontend.  My slowdowns were
only observed in mythmusic -- while debugging I saw the gratuitous selects.
Now my mythmusic starts up in 2-3 seconds (which is still slow IMO) and
as others have pointed out, the next biggest bottleneck is in playlist
editing.

Thanks for the feedback,