I take it this is all via SlimServer? Are you seeing this when using Rhapsody via Squeeze Network? I'll take a look at this a little later, I'll need to add quite a few tracks to try to reproduce this. 

Does it work when browsing on the player with the remote?

Another thing to try is reducing your items per page setting from 425 to the default of 50.  Getting large lists of hundreds of items will take longer and use more memory than only getting 50 at a time.  This setting is at Server Settings -> Interface by the way.

One other thing, browsing by tracks with the remote is a bad idea, as all 2900 items will be returned at once from the server.  I would highly recommend not browsing by tracks, and use the albums menu instead.

Thanks for the comments.  Here are my responses:

To comment 1 -- I do not know what Squeeze Network is, I'm sorry.  I use the web interface to SlimServer.

To comment 2 -- I set the number of menu items to 425 intentionally, in order to work around another bug, the one pertaining to a limit on the number of menu items starting with "Z" that can be located by the software.  See bug 4222, https://bugs-archive.lyrion.org/show_bug.cgi?id=4222 , where I was advised to take this action.  As to memory consumption concerns, possibly I'm in the wrong here, but I cannot imagine that 425 track, album, or any other entries could take up an amount of memory that could be considered significant in a 2007 context.  How long could a track record possibly be?  3Kb?

To comment 3 -- I guess my original post didn't make completely clear that I am using the web interface, not the remote control (although I would have thought that "selecting a specific page number" would have been the giveaway, as I don't know that that can be done from the remote control).  In any case, I am using the web interface, and would like to be able to step through the tracks properly.

Thanks for your help.

Andy do you want me to do any testing for this? 

Ross: If you can reproduce it that would be great.  I am using the latest 6.5.2 and am unable to reproduce.  I can browse all 9 pages of my 3576 Rhapsody tracks with an 'items per page' value of 425.

Matt: Have you tried setting it back to 50?  What happens then?

Andy: Could you shoot Julien another email requesting a Rhap account for me? 

Hi Andy,

I just installed the latest SlimServer Nightly (3/15).  I can browse to the third set of 425, but no further.  When I switch to 50, I can make it to page 23 (items 1101-1150), but no further.  It is as if IE is timing out, saying "I'm not waiting any longer for a response from this server".  But it doesn't give a "can't load page" or any such, it just refreshes what I already have.

Just to be clear, I am using the web interface from a remote computer, not the music computer.  Possibly your computer is faster than my music computer?  Possibly you're running locally?  I can imagine the response might be faster, or at least different, and a timeout avoided, under those circumstances.  Given the way the error is occurring, it is as though each time SlimServer has to rebuild the list from the start in order to give the desired entries, and at some point that list building just takes too long and the browser times out.  Maybe.  Anyway that's what it seems like, whether it's what's really happening or not.

Thanks for your help.

Hmm, but every page of only 50 items should be quick to display, since the UPnP server will only send back 50 items.  Try running with some debug switches to maybe get more info.  I would concentrate on the page that fails when in 50-mode (1101-1150).  Just request that page without going to the other pages and see if it fails.

Use this command line to run SlimServer:

slim.exe --d_upnp --d_http_async

Ross, please see me for the QA rhapsody account info.  Thanks.

I can't seem to reproduce this either. Setting Items per page to 425 I can browse to the 3rd page of tracks without a problem (beyond a reasonable hesitation). Let me know if you'd like me to test anything else. 

I've retried this and still cannot get beyond page 3, or even to it now.  I'm sorry but I have not had the time to go through running this with the debug switches, but I may do so.

Ping? Matt have you had time for debugging? I'm still unable to reproduce this. 

Thanks for the reminder.  I had gone back down to 6.3, or whatever, and then back up to the official 6.5, or whatever.

Anyway, here's what I did.  I ran slim.exe with the debug switches you mentioned.  My tracks/page was still set at 425.  Page 1 of the tracks came up OK.  I requested page 3, and it did come up, but at that point I could get nothing else.  I think the appearance of page 3 is somewhat random, as it didn't come up the first time I tried it.

Here is the relevant portion of the logfile:

2007-07-24 17:51:12.3486 Async::HTTP: Read body: 1024 bytes
2007-07-24 17:51:12.3497 Async::HTTP: Read body: 1024 bytes
2007-07-24 17:51:12.3510 Async::HTTP: Read body: 1024 bytes
2007-07-24 17:51:12.3520 Async::HTTP: Read body: 713 bytes
2007-07-24 17:51:12.3694 Async::HTTP: Body read
2007-07-24 17:51:12.3697 SimpleAsyncHTTP: status for http://127.0.0.1:59452/ContentDirectory/control is 200 OK
2007-07-24 17:51:12.3700 SimpleAsyncHTTP: Done
2007-07-24 17:51:21.0385 SimpleAsyncHTTP: GETing http://127.0.0.1:59452/
2007-07-24 17:51:21.0401 Async: Connecting to 127.0.0.1:59452
2007-07-24 17:51:26.0859 Async: Failed to connect: No such file or directory
2007-07-24 17:51:26.0869 Async: Connect timed out
2007-07-24 17:51:26.0872 Async::HTTP: Error: Connect timed out
2007-07-24 17:51:26.0875 UPnP: Rhapsody (mattcd2) failed to respond at http://127.0.0.1:59452/, removing. (Failed to connect to http://127.0.0.1:59452/ (Connect timed out)
)
2007-07-24 17:51:26.0878 UPnP: Device went away: Rhapsody (mattcd2)


I had mentioned earlier that the problem seemed like a timeout of some kind.  I'm not sure whether to feel vindicated in that believe by the words "timed out" in the above, since there are different kinds of timeouts.  As you can see, something did not get responded to and it crapped out.

I hope this helps.  Thanks for your help.

It sounds like your Rhapsody server can't handle the request, maybe you should lower your items per page value.

(In reply to comment #15)
> It sounds like your Rhapsody server can't handle the request, maybe you should
> lower your items per page value.

Thanks Andy.  As I discussed earlier in the thread, it fails in that case also.  However, the debug seems to show that it fails a bit differently.  I was able to get the 23rd page of tracks; it failed on the 24th page.  Here is the relevant part of the log file:

2007-07-24 21:04:50.5618 Async::HTTP: Read body: 1024 bytes
2007-07-24 21:04:50.5657 Async::HTTP: Read body: 1024 bytes
2007-07-24 21:04:50.5667 Async::HTTP: Read body: 284 bytes
2007-07-24 21:04:50.5678 Async::HTTP: Read body: 1024 bytes
2007-07-24 21:04:50.5689 Async::HTTP: Read body: 1024 bytes
2007-07-24 21:04:50.5699 Async::HTTP: Read body: 1024 bytes
2007-07-24 21:04:50.5708 Async::HTTP: Read body: 1024 bytes
2007-07-24 21:04:50.5718 Async::HTTP: Read body: 284 bytes
2007-07-24 21:04:50.5729 Async::HTTP: Read body: 1024 bytes
2007-07-24 21:04:50.5739 Async::HTTP: Read body: 1024 bytes
2007-07-24 21:04:50.5749 Async::HTTP: Read body: 635 bytes
2007-07-24 21:04:50.5794 Async::HTTP: Body read
2007-07-24 21:04:50.5797 SimpleAsyncHTTP: status for http://192.168.1.6:63326/ContentDirectory/control is 200 OK
2007-07-24 21:04:50.5799 SimpleAsyncHTTP: Done
2007-07-24 21:04:51.0157 SimpleAsyncHTTP: GETing http://192.168.1.6:63326/
2007-07-24 21:04:51.0171 Async: Connecting to 192.168.1.6:63326
2007-07-24 21:04:54.1737 Async: connected, ready to write request
2007-07-24 21:04:54.1744 Async: Sending:
GET / HTTP/1.1
Connection: close
Cache-Control: no-cache
Accept: */*
Accept-Encoding: gzip, deflate
Host: 192.168.1.6:63326
User-Agent: iTunes/4.7.1 (Windows; N; Windows XP; 586; EN; cp1252) SlimServer/6.5.2/12069
Icy-MetaData: 1

2007-07-24 21:04:54.1760 Async::HTTP: Error reading headers: Server closed connection without sending any data back at /PerlApp/Net/HTTP/Methods.pm line 306.
	...propagated at /PerlApp/Net/HTTP/NB.pm line 32.

2007-07-24 21:04:54.1767 Async::HTTP: Error: Error reading headers: Server closed connection without sending any data back at /PerlApp/Net/HTTP/Methods.pm line 306.
	...propagated at /PerlApp/Net/HTTP/NB.pm line 32.

2007-07-24 21:04:54.1979 UPnP: Rhapsody (mattcd2) failed to respond at http://192.168.1.6:63326/, removing. (Failed to connect to http://192.168.1.6:63326/ (Error reading headers: Server closed connection without sending any data back at /PerlApp/Net/HTTP/Methods.pm line 306.
	...propagated at /PerlApp/Net/HTTP/NB.pm line 32.
)
)
2007-07-24 21:04:54.1989 UPnP: Device went away: Rhapsody (mattcd2)


Hope that helps.

Both logs show that the Rhapsody UPnP server crashed or was too slow in responding.  You could try increasing the server timeout value (Server Settings -> Network), but other than that there isn't much we can do.

Hi Andy,

That fixed it.  My probably not terribly accurate stopwatch test showed that, for instance, page 69 of tracks (using 50 tracks per page) came back in 4.29 seconds, so apparently the 3 second default was just a _little_ too slow for my particular setup.  At 425 tracks per page even 20 seconds (which is what I set it to) isn't long enough, so I may not be able to continue to use the 425 track setting.

Anyway . . . thanks much.  I guess this bug should be set to WORKSFORME, but I'm not sure, so would someone else please set the appropriate resolution?  Thanks.

This bug is being closed since it was resolved for a version which is now released!  Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html

If you are still seeing this bug, please re-open it and we will consider it for a future release.