Alex: can you give us some additional information about your setup? How is your player connected (wireless, wired), what kind of router are you using and encryption type, what kind of audio are you playing, etc.  We'd love a way to reproduce this problem.

Squeezebox2 rev 63 is connected to a nightly 6.5b3 on a Windows 2003 server via wireless 802.11G with WPA to a Linksys WRTP54G ver 1.00.62. No music is played at the time of the crash - early morning. I usually perform a daily library rescan at 5:00AM and the alarm is usually for 7:00AM. Sometime in between the hours the crash has been occurring. I have rerun the rescan during the day to see if the problem may exhibit itself, but it has not. Music is about 70/30 of FLAC/mp3 respectively.

Please let me know if I can assist further.

Ross, can you look at setting up an SB2 to reproduce this before you go tonight, and we'll see in the morning if it's reproducible?

Set up both the automatic rescan and alarm as Alex describes, and have the alarm play a playlist of one mp3 and one flac file.  Come and grab a wireless router from me.

It looks like the WRTP54G is kind of a strange creature.  If you can't reproduce the issue, we should probably buy one to have for testing.

This is probably releated to a malloc error that Kevin told me about. A "malloc error" is only reported by the firmware during setup or when re-connecting to slimserver/wlan. So far I have found a low memory condition can occur by repeatedly rebooting an access point (simulating a bad wireless connection).

I find it very unlikely that the alarm is the cause of the "malloc error", and it is more probably this happens at some stage during the night. It might be more constructive to setup an access point on a timer switch so that continuously reboots and see if that can trigger the error.

Here are some additional information about the environment:
- according to the sb2 the wireless connectivity is between 65% and 85%
- during the rescan process the sb2 stops updating the seconds of the clock at many intervals
- during the scan, the server is not busy at all in terms of CPU or memory consumption and 

The fact that the SB2 clock display stops updating means it doesn't have good connectivity with the server.  It's such a 'slim device' that SlimServer actually generates the text displayed on the screen, and when it's displaying the clock sends updates several times a second.

So if the seconds are not updating, either the packets carrying the clock display are not getting through due to network issues or the server software or hardware is so overloaded it can't generate and send out the display frames in a timely manner.

Since you say the server does not report being busy, perhaps it's a network issue.  I note the WRTP54G router is a VOIP router, so it probably gives VOIP packets very high priority and ordinary old "data" packets (such as slimserver :) a much lower priority.  I'll just go ahead and get one so we can check out the specifics.

Chris let me know if you'd like me to try anything out here, particularly when you pick up the VOIP router I wouldn't mind peeking over your shoulder. 

Alex, we would be able to identify if this has anything to do with your SlimServer, if you could install SlimServer on another computer on the network. Is that possible, just as a diagnostic?

Alex I have been looking at trying to recreate the malloc failure today, and looking at causes of low memory in the player. I need a little more information from you. Do you have anything connected to the Ethernet port of the Squeezebox (either as a bridge, or something connected but unused)? And do you have any other devices connected to your network during the crash, other than the server and wlan?

Thanks,
Richard

And also ... How many other wireless lan's can you see in the setup menus?

I really want to get this bug fixed, but I need more information on how to recreate. I'm retargetting to 7.0.

re comment 8: yes. please take a look at bug 4154 - apparently I did not have a crossover cable required for bridging my HP JetDirect EX. The device is not functionning.

I have 3 more Windows XP boxes on the network: 2 laptops via WLAN and one desktop via the LAN port. The desktop is on all the time, the laptops were off during the incident(s).

re comment 9: no, I do not have any other networks displayed. I do have another network in the house, but it is not broadcasting the SSID.

P.S. I have not seen the issue since I posted this bug. I have been upgrading to the latest nightly builds of 6.5 series.

So one early morning, I once again had my SB constantly disconnecting from SS. Unable to figure out why, I switched the SB to connect to the SqueezeNetwork. Once it connected, I got the malloc error again, the SB restarted, and then it no longer had connectivity issues again, even after I switched the SB to connect to SS.

Let me know if you need additional information.

Please try the latest firmware (squeezebox 69 / transporter 24) that will be in
the Nov 22 nightly slimserver 6.5.1 release. This may prevent the malloc error
messages.

I have isolated that for me, the malloc error (prior to the squeezebox 69 release) occurred only when connected to the squeeze network. Otherwise, when connected to SS, SB would just reboot, without the malloc error.

Now, post the squeezebox 69 release, I still experience reboots. I have not yet received any errors on the squeeze network. (I have not used the squeeze network as often as the slim server.) Just wanted to provide you with an update to the bug.

Haven't seen this in the latest firmware.  Alex: please feel free to reopen if you see this with the firmware included with 7.0.

This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html