Bugzilla – Bug 1497
Browsing music folder is exceptionally slow; causes server to become unresponsive
Last modified: 2009-09-08 09:22:30 UTC
Browsing the music folder is incredibly slow; so slow, in fact, that the server becomes unresponsive otherwise, causing display freezes on the player and music dropouts (at least on SB1 players). The problem is exacerbated by user expectations for this function: intuitively one feels that simply listing a directory should be a fast operation. The problem is that behind the scenes this operation is entwined with database lookups and (possibly) updates. In addition, there is a sense that browsing the music folder was faster in the 5.4 server and that performance has degraded in the 6.0 server.
Yes, 6.0 is much slower than 5.4.. I thought the whole point of going to a real database was to speed up the server. I have just under 4000 songs, with 110 artists and 300 albums. I really don't understand what the code could possibly be doing to make it so slow; these numbers are just not very big, even if you are using O(n^2) sorting and insertion algorithms. If I do random play on my entire collection, then want to delete some songs using the web interface, each deletion takes 15-20 seconds (as an aside, the interface would be better if I could mark several songs, then delete them all at once). If I delete the database and restart the server, it takes about 20 minutes to rebuild. The remote is sometimes very unresponsive, taking seconds to react. This is just not acceptable. I can read the tags from all my mp3 files in less than 18 seconds, for reference: % time find . -name "*.mp3" -print0 | xargs -0 id3info | wc 47694 239441 1748087 find . -name "*.mp3" -print0 0.02s user 0.03s system 0% cpu 14.627 total xargs -0 id3info 9.90s user 7.31s system 97% cpu 17.621 total wc -l 0.04s user 0.17s system 1% cpu 17.618 total so disk I/O is maybe 1.5% of the time you're taking to build the database. The database seems bigger than it should be, but still is not very big, only 4Mb: % ll -h -a .slimserversql.db -rw-r--r-- 1 slimserv slimserv 4.0M May 8 23:27 .slimserversql.db so shouldn't present much of a problem. For reference, I have a dual 600Mhz P3 with 1Gb RAM running redhat 7.3. Not exactly a fast machine, but really should be sufficient.
Greg & Steve: How many items are in your folders as you browse them? Also, are you using the remote or web interface? Can you give some timing measurements and details about your setup?
Hi Dean, I'll work on getting some more detailed measurements for you -- can I assume that you prefer I do this against the 6.1 branch? I'm in the process of upgrading to a new machine (dual 2.8 GHz Xeon w/ 4Gb RAM running FC3); do you prefer timing measurements on that or my old dual 600MHz P3 w/ 1Gb RAM running RH7.3? I'm adding you to the CC as I don't know you'll see this update otherwise.
Yes, please make any measurements against the 6.1 tree, and use the latest build (dan made some significant performance improvements last night :) I don't think that it will matter if you use a slower or faster machine, except that the problem will be more obvious on the slower machine.
Browse Music Folder has undergone a complete rewrite - it's very fast now, on the 6.1 tree, soon to become 6.1 beta.
great, I was planning to finally try the 6.1 branch this weekend.. thanks!
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!