A point about playlist creation and shuffling. For a long time I did what it sounds like you are trying to do -- maintain a large playlist of songs that I like, and play it in shuffle mode. I think my list got up to around 3k songs, but I forget exactly.
Anyway, I also noticed that adding tracks to the playlist became slower as the list became larger. But this was exacerbated by having shuffle enabled *while creating the playlist*. What I observed was that as I added each track to the list, it also re-shuffled the entire list. So naturally it took much longer for it to re-shuffle a list of 3k tracks than it would for it to re-shuffle a list of 10 tracks. What I ended up doing was turning off shuffle while I was adding tracks to the list. This shouldn't be a problem unless you want to be playing that same list while you are adding to it. But it sounds like that's what you want to be doing. If you had an extra SB (or softsqueeze) you could use, you could always copy your playlist and then add to the new copy (unshuffled) on your extra SB or softsqueeze, while the original copy (shuffled) plays on your other players. Periodically you could delete the original copy, begin playing the playlist, make another copy, and then begin editing that. Obviously this is somewhat kludgey. But there are going to be compromises when you have a large library, a large playlist which is constantly being reshuffled, playing music in a format which requires transcoding, and a low powered server. For what it's worth, I now use the random mix plugin, and am loving it. On Mon, May 19, 2008 at 5:18 PM, larrettp < [EMAIL PROTECTED]> wrote: > > No, it's directly proportional to the size of the playlist. My point > always has been that size, in a well designed database should not be an > issue. Indexes and the removal of many-to-many tables would help > greatly. However, removing the many-to-many tables would mean code > changes. A quick way round i would be to index both columns in the > 'm-to-m's and also to index the corresponding columns in the parent > tables. This would increase the scanning time as the indexes would nee > to be populated but it would speed up retrieval. > > > -- > larrettp > ------------------------------------------------------------------------ > larrettp's Profile: http://forums.slimdevices.com/member.php?userid=10191 > View this thread: http://forums.slimdevices.com/showthread.php?t=45261 > > _______________________________________________ > discuss mailing list > [email protected] > http://lists.slimdevices.com/lists/listinfo/discuss >
_______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
