Bug 3250 - report that when a large playlist is used as a favorite, playing the favorite causes significant lag
: report that when a large playlist is used as a favorite, playing the favorite...
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Playlists
: 6.5b1
: Macintosh Other
: P2 normal (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-06 11:14 UTC by Kevin Pearsall
Modified: 2008-09-15 14:39 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Pearsall 2006-04-06 11:14:38 UTC
Note from customer:

	No, I was careful to let the scan finish. The server was quiet when
I then tried to play the favorite.

	Note again, if I directly select the playlist from "browse
playlists", it starts within a couple of seconds. So this is something about
how favorites is handling playlists, not playlists themselves.
Comment 1 Kevin Pearsall 2006-04-06 11:15:23 UTC
have not reproduced myself, fyi.
Comment 2 Chris Owens 2006-04-06 11:23:12 UTC
how large are we talking here?  100 tracks?  1000?  10000?
Comment 3 Eric Bergan 2006-04-06 11:48:11 UTC
The original comments on the support email covered configuration, but don't seem to have been included.

I have about 6800 tracks total. Most playlists are about 1000-1500, although one is 5000. Its definitely a factor of the size of the playlist, a small playlist made into a favorite starts quickly.

As mentioned, even the 5000 track playlist only takes a few seconds if chosen from browse playlist. Its only when one is assigned to a favorite, and then the favorite is executed, that it takes 10-15 minutes.
Comment 4 KDF 2006-04-06 11:49:14 UTC
probably related to bug 2373, since the favourites are stored as urls.  playlists from browse playlist are played by id. 

favourites uses playlist add, whereas browse playlist uses playlist addtracks.  

 
Comment 5 Blackketter Dean 2006-04-22 21:55:34 UTC
Chris, is this an issue for 6.2.2?
Comment 6 Chris Owens 2006-04-24 12:16:45 UTC
Since it was reported as being with 6.5b1 I don't think it's a showstopper for 6.2.2.

It is reproducible and I plan to come up with a test case to characterize this lag better.
Comment 7 Eric Bergan 2006-04-24 12:21:00 UTC
I initally reported the bug to support as on 6.2.1, and they asked me to try 6.2.2 which also had the problem. Not sure why they set the version to 6.5b1 on the version.
Comment 8 Simon Turner 2006-05-23 11:58:28 UTC
Well, initially this does not seem related apart from that it's dealing with playlists, but short of opening up another bug or perhaps an enhancement it's probably best here.
I'd appreciate it if the "Scan playlists only" only scanned new or changed playlists. At the moment it scans all playlists, whether they've changed or not. If you have a few large playlists (500 tracks plus) then the scan can become very slow indeed. This particularly affects me as I'll make a short playlist on my PC just before I go down to listen to it on my hifi.

Comment 9 Dan Sully 2006-07-25 11:52:46 UTC
Fixed in change 8639