phew.. ok I think I got it. I am testing now. The problem is that DHCP is getting a renewal of the IP address, and this is killing the connection between the SQB and the server. And it does not come back without user intervention.
Here's the analysis. At exactly 2005-12-12 16:54:48.9615, the SQB sends a final slimproto message that it should be sending every 2 seconds or so (a STAT message). But no further messages of any kind appear for several hours after that even though the slimserver says that it is playing. After rebooting, the DHCP is set to its initial value before the slimserver starts, and so all is good again. The variable nature of the stopping is explained by the timeout of DHCP. I checked the messages file and there's a corresponding DHCP renewal at exactly Dec 12 16:54:45. This renewal takes about 3 seconds to complete, and results in the restarting of the network interface, and slimserver seems to be stuck listening on an old socket handle for the next STAT from the SQB.. one that never appears. By following threads on ntpd problems and DHCP, I was able to come up with a limited fix for ntpd, but for the SQB, the only answer is to run with a static IP address. Or perhaps someone at slimdevices can implement something better? Here's a source for much of the information I found: http://lists.ntp.isc.org/pipermail/questions/2005-August/006348.html Richard -- RichardG ------------------------------------------------------------------------ RichardG's Profile: http://forums.slimdevices.com/member.php?userid=801 View this thread: http://forums.slimdevices.com/showthread.php?t=19009 _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
