[mythtv-users] Hey all

[Joseph A. Caputo]

On Monday 01 March 2004 18:18, Johannes Niess wrote:
> Am Montag, 1. März 2004 19:35 schrieb thor:
> > On Monday 01 March 2004 12:46, Johannes Niess wrote:
> > > I suspect inefficient use/not use of mysql. My default playlist
> > > is just short of 600 entries, but it takes about 4 seconds on a
> > > P4 to parse the song list.
> >
> > 	It always loads all of your metadata into memory, the playlist
> > mapping happens afterwards in code, not queries.
>
> So mythmusic does a "Select * from musicmetadata", parses it and
> picks the playlist entries from that?
>
> Databases are made for that. I'm sure you code can't beat mysql.
>
> > > That way mysql has the burden of figuring out playlists, but that
> > > is what databases are made for.
> >
> > 	And playlists within playlists (ie. negative entries on playlist
> > lists)?
>
> Now you are talking about generation of new playlists?
>
> If you mean unions of playlists:
> Select distinct song.id ... where playlist.id = 1 or playlist = 2;
>
> If you mean temporarily disabling entries: Add a bool field to the
> cross table
>
> If you want e. g. to exclude a particullary bad album from an artist
> playlist: use a temporary table for the positive selection and delete
> some entries.
>
> The pseudo-random selection mode is my favorite :-)
>
> Johannes Nieß
>
> P. S: I'm not proposing a rewrite of mythmusic, but do you know
> Class::DBI?

I'm really can't speak to the efficiency of the mythmusic 
playlist-parsing code; however, I seem to recall doing a simple timing 
study way back when, and the loading/parsing of the playlist & metadata 
from the database was reasonably quick, compared to the interminably 
long time it takes to build the tree UI with all of the songs.  Any 
effort to speed up mythmusic needs to focus on the UI, methinks.  Yes, 
I agree it might be nice to have playlist architecture that leverages 
the database more, but I honestly don't think that's going to yield a 
very noticeable speed increase.

-JAC