I have seen sporadic instances of a reboot cycle, but only on wireless SQBen. I have never seen a previously connected to slimserver, wired SQB spontaneously reboot.
I have also noticed some odd behavior with softsqueeze 3.3 on windows XP running a console based slimserver 6.5.2 with "prevent windows standby" plugin active where the screen will freeze up and not respond to the graphical remote, but I'm not convinced that this is directly related since music continues to play. I have not been able to force softsqueeze to randomly stall on the transition (but I have been able to stall it with a particular track.. more on that later). On a similiar note, slightly off topic, but there seems to be so little to go on here, when streaming a radio station through squeezenetwork using the SQB3, I noticed that it too would eventually lock up the display requiring an IR power cycle to correct. I didn't test if a radio station established through the slimserver would have the same result. But I believe that SQBen are always referred to the radio station so that the radio stream does not pass through the slimserver. Finally, I have an mp3 file that plays fine in a player like foobar2000, but locks up slimserver/softsqueeze on windows at the transition like other random tracks. The difference being that this particular track *always* locks at the transition while other tracks do not. At this point, with a bit of a leap in logic, one could look to the slim protocol as the source for these issues. Then the problem would be that the firmware implementation of the protocol is out of sync with the server implementation under certain random circumstances (most likely in the stream error category). One could also speculate that there is a timing problem between the server and the SQB. All devices slip time, and many need to be trained or periodically set to an agreed upon time source. Perhaps the time of the SQB is set to the slimserver initially, but it would be inefficient to check frequently for new time values. If the server has a time adjustment event, the SQB would have a different time (either a future or a past time). Such an event might lead the underlying stack to drop packets at the SQB or the server. Since they are UDP, there would be no ACK.. retransmit. ntpd in SQBen? Or just switch to TCP? Anyway, it would be better if some more obvious problem exists. Things to try at this point include: Check the NIC drivers on your server. Are there any messages in the Administrative Tools event log around the time that the SQB has trouble? Look at services to make sure you don't have a sqld (MySQL) running from an older version of slimserver (check the folder name of the service properties "dir /x"). For softsqueeze, make sure you are using the MP3 Plugin and not the JLayer one. Make sure Audio/Audio Mixer is set to the correct sound card. Use a crossover cable to connect your slimserver and the SQB directly. Let the slimserver play (no plugins, no web browser open, no debugging and no network statistics) until you get the problem. Graduate to only the slimserver and a wired SQB3 on your network. If you don't get the transition problems after a week or two of playing, then work your way forwards by adding things that you use normally. Hopefully you'll find a device with a faulty NIC/driver on the network or a bad plugin. Richard -- RichardG ------------------------------------------------------------------------ RichardG's Profile: http://forums.slimdevices.com/member.php?userid=801 View this thread: http://forums.slimdevices.com/showthread.php?t=33044 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
