Bugzilla – Bug 8857
Boom fails to reconnect to server
Last modified: 2008-08-28 16:58:49 UTC
I'm currently running a 7.2 Boom NS server and a SlimServer 6.5.5 server on my network. I shut down 7.2 Boom NS to do an SVN update, leaving the 6.5.5 server running. After the SVN update I restart the 7.2 Boom NS server and my SB2 reconnects, my SB3 reconnects, and my remote Squeezeslave client reconnects. The Booms do not. They may be getting confused by comm with the 6.5.5 server, maybe not. Both were in the off/standby state when the server was shut down and restarted. The one in from of me right now is displaying '315:715' on the display, slightly to the right of being centered.
The '315:715' on the display means the RTC clock isn't working properly. A known issue on some early Booms when they have been running for a while (i.e. get to a certain temperature). This is fixed in recent hardware. I was wondering if Boom doesn't reconnect all the time when you do a svn update (i.e. stop and start SC) or only sometimes? I tried several times (although my server is running on Ubuntu) and all connected players did reconnect as they should. Hmm. Also, are all your players connected wired or wireless? Does that make a difference? Thanks
I'll do some more testing this evening to let you know if it happens all the time. The newer boom that I have was displaying the correct time while disconnected. All players, with the exception of the remote Squeezeslave client, are connected wirelessly. A couple things that are consistent: 1. When I turn the boom on and begin to communicate it first tells me that it's waking up the server. 2. The display is very choppy, with split display in some cases as the scrolling halts. 3. The interaction is very hit/miss, with many missing remote button clicks and general unresponsiveness. 4. When I get to the connection choice to connect to 'ServerName (IP address)' it displays the _correct_ (previously connected) IP address, and right-clicking into this connects within seconds. Like I said, will do more testing tonight. I want to see what happens if I shut down the SS6.5 server.
QA to try to reproduce
More info: Yes, this is happening every time. The very first thing it displays is something to the effect of "SqueezeCenter needs to be upgraded", so the Booms are definitely latching onto the 6.5 server when the 7.2 server is shut down. Again, the SB2/3 on the network don't have this problem. When the SC 7.2 server is started up again the Booms never go _back_ to the 7.2 server. Seems like the Booms are getting stuck when they displays that upgrade message and never look for another server.
Hi Jim. I'm not able to reproduce this but I'm using the nightly boom builds not SVN. I'll try again with future builds and if that doesn't get anywhere I'll try svn.
(In reply to comment #5) > I'll try again with future builds and if that doesn't get anywhere I'll try svn. Still not seeing this with current builds, also having issues with SVN on 2003 server but Dean notes in terms of this issue it is no different who builds it. Dean also mentions that you might be running two servers on one machine? Are these servers on separate computers or is something else going on that might be different than what you and I are doing?
Yes, both servers are running on the same machine, but on different IP addresses. Have you tried TortoiseSVN? Works great for me on Windows Server 2003. For simplicitly I'm currently only running one server, the 7.2 Boom branch, so I'm not having the problem at the moment. But I still have SlimServer 6.5 installed, so it would take just a minute for me to test again. Another test might be to run an SC version less than 7.2, which, if the Boom attaches to it, would display the same "SqueezeCenter needs to be upgraded" message. I may try it this weekend to see what happens. That's a more likely scenario in the field - where someone is running, say, a 7.1 server and a 7.2 server. Like I say, the main issue is that just doesn't seem very robust when faced with this situation, unlike the SB2 and SB3's on the network, which never attach to a different server. Unlike the Booms they wait for the "remembered" last used server to come back online, otherwise they need manual intervention in connecting to a different server.
We'll see if any others report this