its not possible to browse, but there is very definitely a SEARCH option that
makes it entirely possible.  you may not like this, but as I recall, the browse
songs mode was intended to have been removed a long time ago.  It was certainly
removed from web interface on the basis that it was slow and didn't work. The
'bug' here is really that it was left behind as an option in the player menus.

I believe that browsing songs when not in an Album context should be sorted alphabetically.  Dan, is 
this a hard thing to do?

I was always wondering why the "browse songs" has no counterpart on the web
interface, your comment explained that now.
I know the SEARCH option but I use Browse (for album titles) and Search (for
album titles) in different situations. I am used to set the option in SlimServer
that SEARCH will no only search at the beginning but also within a word so
SEARCHING finds a lot of matching results (which I like in some cases). But
Search is hard to use since I have to input a lot of characters to reduce the
number of found results. I usually use BROWSE to quickly jump to the beginning
of the next character block by inputting the start character and then browse
through the shown results with the arrow down key. So in some cases you would
find a desired song much faster if the songs were sorted alphabetically when
using "browse songs".
I noted that the first time when I selct browse songs it takes about 2 minutes
until the song list is shown on my Squeezebox2 (I have about 5500 songs).
Selecting browse songs at a later stage takes only about 10-12 seconds. The 2
minutes prevented that I use browse songs in practice. The sorting issue was an
additional drawback.
So for me changing the sorting (if this should be possible) should be combined
with an acceleration of preparing the song list (which seems to be possible
since the second trial needs only 10 seconds).

At the moment I have deleted browse songs from the menu.

Dieter

Dean,  the sorting is specified as 'title' in the code, but for some odd reason
doesn't actually give results to match. I suspect that the common use of 'track'
listing as a sublevel has left it susceptible to client param data that might be
left around from previous modes.

kdf - do you have time to look into this?

Thanks.

ok, I have a solution for this but I have concerns over hos it affects other
browse modes.

for track listings, we sort by track number when an album has been previously
selected.  What should be the right order when it comes to 'artist', or 'genre' ?

Dean, is track title sorting sufficient here as well?

if it's not filtered by album, then they should be in alphabetical order.  

ok, cool.  That means it looks like all we need is to change Pages.pm, line 92 from:
return $ds->find('track', $findCriteria, exists $findCriteria->{'album'} ?
'tracknum' : 'track');
to:
return $ds->find('track', $findCriteria, exists $findCriteria->{'album'} ?
'tracknum' : 'title');

I can merge that in tonight if there is no problem with that.

Sounds good!
Do you have an idea why the first selection of browse songs takes so much time
whereas the next selection is much faster?

it takes so long becuase you are finding and sorting a huge number of items.
after that, I suppose there is some level of caching that goes on, same find
key, same results. I wasn't really aware of any caching, but I'm not a db
expert.  I guess you can consider it a bonus that its quicker after the first
time :)

fix commited at change 3671.  update svn or download July 12, nightly.

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!