I also had serious performance issues with browsing, running mt-daapd on an NSLU2, and fixed most of them as follows:
1) Overclocking the slug was super easy (using just tweezers, no solder), and this gave me a 30% performance boost for getting the full Artists list. See http://www.nslu2-linux.org/wiki/HowTo/OverClockTheSlug.
2) Cleaning or splitting your music collection to sets of 5K or fewer songs, if possible, would fix the problem. In my case, most of my mp3s were in a backup folder that was double-indexed (doh!). Moving that folder and deleting some other junk brought the number of songs well under 10K. You might also consider splitting your collection and running multiple instances of firefly as discussed in http://forums.fireflymediaserver.org/viewtopic.php?t=4688, though this seems like a last-resort hack.
3) Indexing the artist/album/genre columns of the songs table gives a huge improvement for browsing with partial criteria (eg give me all albums for artist X, or give me all artists for genre Y). But as you noticed, it does not affect the query for a full list of artists, albums, and genres. This is because the index affects only queries where that column is in the search criteria (e.g. “select * from songs where artist=’X'”) not queries where that column is just in the results (e.g. “select artist from songs”).
On my system, it now takes 6-8s to get the full Artists list from Firefly. Not as bad as your 30s delay, but still unacceptable IMO to begin every browse.
In my case, I looked for a solution on the client, not the server. I use a wireless PocketPC running VisualMR to control my SoundBridge, and Thorsten, bless his soul, was kind enough to implement client-side caching of the artist/album/genre lists in VisualMR 1.5. Since my PocketPC is always on, getting the full list of artists, albums, or genres is now instantaneous. No Firefly queries, no SoundBridge commands, no wireless roundtrips. I only need to clear the cache and re-fetch the lists of artists, etc. when I add new files on the server.
I’m guessing that this performance issue could also be fixed on the server if Firefly maintained a separate “artists” table in songs.db. Then the database would not need to scan the entire “songs” table to get the list of artists, which is much smaller than the list of songs. Ditto for albums and genres. If enough people are running Firefly on slow NAS units with large music collections, perhaps Ron will consider this. It can’t hurt to ask, anyway. 🙂
Happy listening – hope this helps!
Linksys NSLU2 — 266Mhz, EXT3, Unslung 6.8 beta, Firefly svn-1450
SoundBridge M1001 — 2.7.50, WPA-TKIP
Dell Axim X30 — WM2003SE, WPA-TKIP, VisualMR 1.5.0