[mythtv] patch: setsetting -> db
dert at pobox.com
Mon Feb 24 19:42:39 EST 2003
#if Isaac Richards /* Feb 24, 19:06 */
> No, you're not. In that case, you'd make your settings object visible to what
> needs to change it -- just like the existing ThemeSelector object could be
> made visible to the code in mythfrontend's main.cpp if wanted to. It even
> was visible to the main.cpp once, the current layout (all the classes inside
> globalsettings.cpp) was just put in place to speed up compilation a bit.
> Changing it back would be the work of a couple minutes.
I'll take your word for it. It sounds more complicated than simply
issuing a SetSetting() in exactly the same style as a GetSetting().
> By the way -- your playlist schema changes are 4 times faster than the current
> code at reading in a playlist, and a good 10 times slower (on average, it's
> up to 20 times slower for large changes to the playlist) at writing out a
#endif /* ijr at po.cwru.edu */
Which is why I wanted the changes to the playlist to only happen only once
per selection or de-selection of tracks, during playlist creation. This
would mean that one would never update the playlist in the database except
to add or remove a track/album/artist to the playlist. There would be no
SaveDefaultPlaylist() because it would be crafted incrementally elsewhere.
This is best accomplished, IMO, when we move to real Playlist objects that
can encapsulate the management of database synchronization.
You've said that it takes your mythmusic 1/10th of a second to save/load a
playlist, but I've heard several complaints now that the slowdown is in
editing a playlist. Even with my limited music collection, it takes a
couple seconds. I believe this is disk I/O and unrelated to the DB, though
it is clearly querying the database once for each entry in the playlist
and perhaps even each entry in the musicmetadata table. I don't see why
it can't issue a single query for that data.
More information about the mythtv-dev