Are you sure the service is actually starting when your players don't connect?  I restart my development SlimServers all the time and have never seen this happen unless I had a network problem.  Try hitting port 9000 next time it happens.

Yes, the service always starts.  I always look at the home page in the web interface to see if the players connected.  I'm running the http server on port 80.  I wouldn't rule out a Windows networking issue, but wouldn't know where to begin debugging the problem.  Recommended debug switches?

You could try --d_slimproto to see if any messages from the players are being received.  Do the players connect if you interact with them or power cycle them?

Here's a good one.  The Softsqueeze client is :17 and resides on a remote network, while :21 and :d4 are two local Squeezebox2s.

2006-07-19 16:05:06.4126 new client id: (00:04:20:05:a6:21)
2006-07-19 16:05:06.4129 New client connected: 00:04:20:05:a6:21
2006-07-19 16:05:06.5369 new client id: (00:04:20:05:d0:d4)
2006-07-19 16:05:06.5375 New client connected: 00:04:20:05:d0:d4
2006-07-19 16:05:06.6449 new client id: (bd:be:0c:63:6e:17)
2006-07-19 16:05:06.6455 New client connected: bd:be:0c:63:6e:17

Here's a bad one.  Audrey is the name of the server.  Looks like it just spins and spins, with no sign of the Softsqueeze client.  Right now I have about 12 minutes worth of the following in my log file.

2006-07-19 16:12:17.0724 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:a6:21
2006-07-19 16:12:17.0725 It's a Squeezebox
2006-07-19 16:12:17.0726  calculated audrey            length: 17
2006-07-19 16:12:17.0727 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:17.0767 Use of uninitialized value in hash element at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 153.
2006-07-19 16:12:17.1816 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:d0:d4
2006-07-19 16:12:17.1816 It's a Squeezebox
2006-07-19 16:12:17.1817  calculated audrey            length: 17
2006-07-19 16:12:17.1818 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:17.3224 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:a6:21
2006-07-19 16:12:17.3225 It's a Squeezebox
2006-07-19 16:12:17.3226  calculated audrey            length: 17
2006-07-19 16:12:17.3227 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:17.4313 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:d0:d4
2006-07-19 16:12:17.4314 It's a Squeezebox
2006-07-19 16:12:17.4315  calculated audrey            length: 17
2006-07-19 16:12:17.4316 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:17.7817 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:a6:21
2006-07-19 16:12:17.7818 It's a Squeezebox
2006-07-19 16:12:17.7818  calculated audrey            length: 17
2006-07-19 16:12:17.7819 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:17.8906 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:d0:d4
2006-07-19 16:12:17.8907 It's a Squeezebox
2006-07-19 16:12:17.8907  calculated audrey            length: 17
2006-07-19 16:12:17.8908 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:18.4232 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:a6:21
2006-07-19 16:12:18.4233 It's a Squeezebox
2006-07-19 16:12:18.4234  calculated audrey            length: 17
2006-07-19 16:12:18.4235 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:18.5319 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:d0:d4
2006-07-19 16:12:18.5320 It's a Squeezebox
2006-07-19 16:12:18.5321  calculated audrey            length: 17
2006-07-19 16:12:18.5322 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:19.2767 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:a6:21
2006-07-19 16:12:19.2769 It's a Squeezebox
2006-07-19 16:12:19.2770  calculated audrey            length: 17
2006-07-19 16:12:19.2772 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:19.3855 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:d0:d4
2006-07-19 16:12:19.3856 It's a Squeezebox
2006-07-19 16:12:19.3857  calculated audrey            length: 17
2006-07-19 16:12:19.3858 gotDiscoveryRequest: Sent discovery response.
2006-07-19 16:12:20.0357 Use of uninitialized value in hash element at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 153.
2006-07-19 16:12:20.1340 gotDiscoveryRequest: deviceid = 4, revision = 3.11, MAC = 00:04:20:05:a6:21
2006-07-19 16:12:20.1341 It's a Squeezebox
2006-07-19 16:12:20.1341  calculated audrey            length: 17

etc., etc.

Ah well, I ended that fun after 30 minutes and almost 2GB logged.  Restarted the service and all three connected within seconds.  I was probably incorrect about it happening 1/3rd of the time as it took me about 8 or so attempts to get it to fail.

Do you want this bug, Andy?  Should I work on trying to reproduce it?

I'd really like to see if it can be reproduced.

Any other suggestions for debugging this?  I take it that the above wasn't any help.

CCing Richard as this may be a firmware bug.

(In reply to comment #9)

As a result of my General Forum posting 124797, Andy asked me to look at this bug.

My problem seemed similar to this bug.  So while the computer was running, I stopped Slimserver and the screen on the Squeezbox went blank.  When I restarted Slimserver, the Squeezebox screen lit up and I could reconnect.

Not sure what this means.


Fred R.

(In reply to comment #10)
> (In reply to comment #9)
> As a result of my General Forum posting 124797, Andy asked me to look at this
> bug.

So I tried another experiment....

I turned off the computer.  The Squeezebox screen went blank.  I turned on the computer and Slimserver started automatically but the Squeezebox screen was still blank.  I pressed the Power button on the remote and the Squeezebox screen remained blank.  I tried other remote buttons without success.

So, my conclusion is that turning off Slimserver while the computer is running does not seem to adversely affect Squeezebox.  But turning off the computer shuts down Squeezebox and it will not restart unless I pull the power cord out of Squeezebox and reinsert it.

Hope that helps.

Fred

The more I play with this the more I'm convinced the problem is at the server.  That the Softsqueeze client fails to connect or else is successful in tandem with the Squeezebox2s would seem to point in that direction.

To answer Andy's earlier question of

> Do the players connect if you interact with them or power cycle
> them?

No.  They always get stuck on the 'Connecting to SlimServer...' message.  The only difference is the display - normally they remain blank if I stop then restart SlimServer.  The Squeezeboxes are getting onto the wireless network and obtaining ip addresses, so it's not a network issue.  I've tried three ways of goosing the players into connecting, all with the same results.

- left-arrow into setup, then immediately right-arrow to connect with the server
- left-arrow into setup, then step through the networking setup, making no changes
- power cycle

And only fixed by restarting SlimServer.

Well, this is starting to sound more like you two have different bugs.

Fred, are you also running FW59 with a recent 6.5 build?  Also under XP?  Even powering down my server and unplugging the ethernet cable for good measure I couldn't reproduce this.

Is there anything unusual about how your network is set up?

(In reply to comment #13)
> Well, this is starting to sound more like you two have different bugs.
> Fred, are you also running FW59 with a recent 6.5 build?  Also under XP?  Even
> powering down my server and unplugging the ethernet cable for good measure I
> couldn't reproduce this.
> Is there anything unusual about how your network is set up?

I am running 6.31.  I did run 6.5 at one time and switched to 6.31 when it was released.  I also got some help from your support group is solving a problem (by deleting some files and reinstalling 6.31) with intermittent Slimserver stoppages.  Seems to me that I didn't have these problems with 6.5. Not sure what FW59 is???

I don't think there is anything unusual in my setup.  I am running from my desktop which sends a wired signal to a repeater in another room.  The repeater communicates with Squeezebox.

Per Jim Z's request, here is some additional info.  I am running XP.  I went to XP's "Services" and stopped Slimserver (which was already "Started".)  I restarted the Service and Squeezebox lit up and connected.

Fred

I have --d_slimproto turned off and just --d_info enabled.  The error below is logged repeatedly when the Squeezeboxes don't connect.  If you look closely, it was also seen in the log snippit above.  It does not appear when the Squeezeboxes can connect.

2006-07-30 01:03:29.8872 Connected to database dbi:mysql:database=slimserver2;host=localhost - schema version: [2]
2006-07-30 01:03:30.4033 loading types config file...
2006-07-30 01:03:32.3375 Use of uninitialized value in hash element at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 155.
2006-07-30 01:03:34.1936 Use of uninitialized value in hash element at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 155.
2006-07-30 01:03:35.4190 Use of uninitialized value in hash element at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 155.
2006-07-30 01:03:37.2475 Use of uninitialized value in hash element at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 155.
2006-07-30 01:03:38.6217 Use of uninitialized value in hash element at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 155.
2006-07-30 01:03:40.3171 Use of uninitialized value in hash element at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 155.

I just saw change 8827 come across the checkins mailing list.  It didn't mention this bug but it looked familiar.  I did an SVN update and I think it just might have solved the problem.  I've done a dozen or so restarts of SlimServer and all of the players have reconnected each time.

I'll report back when I'm certain.

I'm not convinced that change 8827 would avoid these symptoms.

However there have been a few changes to related code recently so please post 
any problems you have with the latest 6.5.

Please test with --d_slimproto if you still have a problem.

I can confirm that it didn't fix the problem.  Oh well.

Created attachment 1418 [details]
log

Still having this problem.  Here's another log with only --d_slimproto enabled.  It consists of one startup with two players successfully connecting, followed immediately (beginning at line 214) by a restart in which the players did not connect.  The only log entry when unsuccessful is the endlessly repeated

Use of uninitialized value in hash element at... Networking/Select.pm line 155.

Jim there was a fix this morning that may have an effect on this problem.  It's in Change 9035.  Can you try that?

Created attachment 1444 [details]
Log with --d_slimproto, showing a new error

No, it's not any better.  That error message shown in comment #19 no longer appears in the logs when there's no connection, however, there appears to be another error.  Also, I have two local SB2 players (synced, if it matters) and am now sometimes seeing one, but not the other connect, instead of all-or-nothing.  See the attached log file for the error.  In this instance the player causing the error (192.168.9.18, MAC ...:d4) connected successfully, while the other is nowhere to be seen in the log.

Ross could you try to reproduce this with today's nightly?  Have both your squeezeboxes connected to your server, stop the server for a few minutes, then restart it.  Since it doesn't happen every time, try it maybe 10 times.

For good measure I tried it 11 times. I was unable to reproduce this. 

I haven't really noticed the problem in the last week or so.  Nothing has been changed with respect to the server or network, so maybe some change within SlimServer has cured the problem.  I'll reopen the bug if the problem returns.

I am experiencing this same problem with SlimServer Version: 7.0a1 - TRUNK - Windows XP - EN - cp1252.  SVN 10420.

I am using ActivePerl to run slimserver.pl from a cmd prompt.

I have two SqueezeBoxes in power off mode.  When I stop the server (Ctrl-C), the screens go blank.  I don't see the usual message (as I do with SoftSqueeze):
  Problem: Lost contact with Slim Server.
  Check the software is running.

When I restart slimserver, the squeezebox screens remain blank (SoftSqueeze displays the Home menu, Now Playing option).

If I press the Power button, I briefly see a message "Waking up Slimserver...", followed a few seconds later with "Connecting to Slimserver..." and then a few seconds later the screen goes blank again.

However, I can get the squeezebox clients to reconnect by pressing the power button again when the "Waking up Slimserver..." message is displayed.  This takes me to the Home menu, Now Playing option.

The above happens for me every time.  The screens always go blank when I stop slimserver, and never automatically reconnect.  I can manually reconnect by pressing power twice.  It's very repeatable.

The only log messages I get (with no debug switches) is:

Use of uninitialized value in concatenation (.) or string at P:\Music\SlimServer\trunk\server\CPAN/Net/DNS/Resolver/Win32.pm line 46.
2006-10-19 22:59:46.2978 Use of uninitialized value in concatenation (.) or string at P:\Music\SlimServer\trunk\server/Plugins/AlarmPlugin.pm line 536, <DATA> line 1.

Reopening, per Phil - it's still happening.

Using Win XP - Pro, SB3 and homeplug ethernet. Static IP addresses. Power to the SB3 is turned off via a surge protector strip after each use. Slimserver is configured to autostart as a service and is running before power is applied to the SB3.

This same thing happened to me for the first time two days ago using 6.5.1 10007 Windows XP EN cp1252. Using the power button the display would light up for a few seconds and then go dark. Restarting Slimserver finally got things going again.

After installing SlimServer Version: 6.5.1 - 10406 - Windows XP (Pro) - EN - cp125 Perl Version: 5.8.8 MSWin32-x86-multi-thread my SB3 is still not connecting to the server using a Netgear homeplug. The homeplug connection had performed flawlessly for 60 days prior to this. Once the connection finally "stabilizes" by restarting slimserver one or more times it performs fine.

I switched back to a wireless connection when I shut down last night (not normally used because of a poor signal) and it connected normally this morning--I'll try the ethernet/homeplug connection again this evening.  

This does not seem to occur with a wireless SB2 (which is always powered on) connected to the same network. 

This appears to be limited to the ethernet connection as I cannot reproduce this with a wireless connection. The problem seems to have worsened and now I cannot maintain a connection to the server for an extended period of time once I finally obtain a connection. Formerly it would maintain a connection once I managed to connect to the server. I hesitate to blame the Netgear XE103 homeplug as I have been using this connection for over two months without any problems. The Netgear diagnostics utility shows no missed, dropped or failed packets and the LED's remain lit indicating that data is continuing to be received via the powerline network. The player will lose connection and the display darkens but the music will continue to play through the buffer until the SB3 reconnects to the server.

(In reply to comment #28)
> This appears to be limited to the ethernet connection as I cannot reproduce
> this with a wireless connection.

I only have wireless devices - it's happening to both of my units, so it's not limited to ethernet connections.

My problem now seems to be isolated to the Netgear XE-103 Homeplug powerline connection. I connected the SB directly to the router via ethernet with no problems. Using the Netgear ethernet connection to both a SB3 and SB-G I repeatedly lost connections to slimserver. I also note when running a SB3 via wireless and a SB-G via the homeplug that generally when the SB-G lost its connection the current song would cease playing through the SB3 but the wireless connnection was not affected. 


Phil's problems are occurring with his wireless connection so my problem may be another issue entirely. Should I file a separate bug report for the powerline ethernet issue? 

Chris, not sure if you will have seen the recent discussion on the forums.  This appears from some of the comments to be an increasing problem for people with 6.5.1. when Slimserver starts up and the SB tries to connect wirelessly.

http://forums.slimdevices.com/showthread.php?t=29230&page=2

Chris,
I have posted in the forum string as well on this.

This is a really annoying issue, and makes it very difficult to "show off" my SB to new (potential customers) people.

Pretty much 100% reproducible on my system as:  "..when I turn the computer on, SB does not start automatically; and it is not detected in the SS web interface. When I press the 'Power On' button on the remote, the SB screen says that it is 'connecting to slim server' and then that it is 'waking up slim server'. The screen then blanks again. Many more presses of the Power On button usually gets the SB connected to SS."

I seem to have fixed my problem.

My problem may have had something to do with IP address allocation.  I was getting frustrated with the reconnection problem, so I restarted my squeezeboxes and went through all the connection settings again, this time changing from dynamic IP addresses to fixed IP addresses.  I noticed that both squeezeboxes seemed to be suggesting that DHCP had allocated the same dynamic IP for both boxes.  Also, my desktop PC hosting slimserver has always had a fixed IP address of 192.168.1.2, but the squeezeboxes were reporting the slimserver IP address of 192.168.1.3.

It was strange because although the boxes wouldn't reconnect, I found that pressing power button twice would force the box to connect and it would be fine until slimserver was restarted.

I recently updated my routers firmware (a Linksys WAG54GX2) - something could have got messed up by that.  I see that other LinkSys routers have had some new firmware releases that have screwed DHCP, so I have stuck with fixed IP addresses.

(In reply to comment #33)
> I seem to have fixed my problem.
> 
> My problem may have had something to do with IP address allocation.  I was
> getting frustrated with the reconnection problem, so I restarted my
> squeezeboxes and went through all the connection settings again, this time
> changing from dynamic IP addresses to fixed IP addresses. 

I have always used fixed a fixed IP address for my SB, so don't think that could be it.

This happened with 6.5.x, so why would the DHCP settings matter?

Here is a slimproto log from last night:
Slimproto running directly from the SS interface...you can see it took about 3-1/2 mins of pushing the on/off button repeatedly to finally connect with the SB3:

2006-11-08 20:25:03.0156 ERROR: Slim::Control::Command::setExecuteCallback() has been deprecated!
2006-11-08 20:25:03.0157 ERROR: Please use Slim::Control::Request::subscribe() instead!
2006-11-08 20:25:03.0158 ERROR: Documentation is available in Slim::Control::Request.pm

2006-11-08 20:25:03.1168 Slim::Web::Pages::addLinks() has been deprecated in favor of
Slim::Web::Pages->addPageLinks. Please update your calls!
2006-11-08 20:25:03.1171 Backtrace:

frame 0: Slim::Web::Pages::addLinks (C:\PROGRA~1\SLIMSE~1\server/Plugins/LastFM/Plugin.pm line 334)
frame 1: Plugins::LastFM::Plugin::webPages (/PerlApp/Slim/Utils/PluginManager.pm line 424)
frame 2: (eval) (/PerlApp/Slim/Utils/PluginManager.pm line 424)
frame 3: Slim::Utils::PluginManager::addWebPages (/PerlApp/Slim/Utils/PluginManager.pm line 197)
frame 4: Slim::Utils::PluginManager::initPlugins (/PerlApp/Slim/Utils/PluginManager.pm line 95)
frame 5: Slim::Utils::PluginManager::init (slimserver.pl line 412)
frame 6: main::init (slimserver.pl line 443)
frame 7: main::main (slimserver.pl line 58)
frame 8: PerlSvc::Interactive (perlsvc.pl line 1486)
frame 9: PerlSvc::_interactive (slimserver.pl line 0)
frame 10: (eval) (slimserver.pl line 0)

2006-11-08 20:28:27.9878 Slimproto accepted connection from: [192.168.2.99:29062]
2006-11-08 20:28:27.9878 Setting timer in 5 seconds to close bogus connection
2006-11-08 20:28:27.9885 _hello_handler: Killing bogus player timer.
2006-11-08 20:28:27.9887 Squeezebox says hello.
Deviceid: 4
revision: 67
mac: 00:04:20:06:50:c5
bitmapped: 32768
reconnect: 0
wlan_channellist: 0000
2006-11-08 20:28:27.9887 Squeezebox also says.
bytes_received: 0
2006-11-08 20:28:27.9889 creating new client, id:00:04:20:06:50:c5 ipport: 192.168.2.99:29062
2006-11-08 20:28:27.1909 *************stream called: q paused: format: url:
2006-11-08 20:28:27.1912 Backtrace:

frame 0: Slim::Player::Squeezebox::stream (/PerlApp/Slim/Player/Squeezebox.pm line 212)
frame 1: Slim::Player::Squeezebox::stop (/PerlApp/Slim/Player/Squeezebox2.pm line 233)
frame 2: Slim::Player::Squeezebox2::stop (/PerlApp/Slim/Player/Squeezebox.pm line 92)
frame 3: Slim::Player::Squeezebox::reconnect (/PerlApp/Slim/Player/Squeezebox2.pm line 68)
frame 4: Slim::Player::Squeezebox2::reconnect (/PerlApp/Slim/Networking/Slimproto.pm line 850)
frame 5: Slim::Networking::Slimproto::_hello_handler (/PerlApp/Slim/Networking/Slimproto.pm line 380)
frame 6: Slim::Networking::Slimproto::client_readable (/PerlApp/Slim/Networking/Select.pm line 238)
frame 7: Slim::Networking::Select::select (slimserver.pl line 492)
frame 8: main::idle (slimserver.pl line 445)
frame 9: main::main (slimserver.pl line 58)
frame 10: PerlSvc::Interactive (perlsvc.pl line 1486)
frame 11: PerlSvc::_interactive (slimserver.pl line 0)
frame 12: (eval) (slimserver.pl line 0)

2006-11-08 20:28:27.1913 starting with decoder with format: m autostart: 0 threshold: 255 samplesize: ? samplerate: ? endian: ? channels: ?
2006-11-08 20:28:27.1914 flags: 0
2006-11-08 20:28:27.1915 sending strm frame of length: 24 request string:

(In reply to comment #35)

Folks, this problem continues.

Another forum thread has sprung up and more people are complaining of same issue!

http://forums.slimdevices.com/showthread.php?t=29536

We need a fix!

I have a problem with a similar issue, not sure if it is the same. One suggestion made in a forum thread was to turn off the PowerSave plugin. It's early days yet to claim this has fixed the problem, but so far it hasn't cropped up since I made that change.

This is what I have for plugins:
Audioscrobbler Submitter 	
	Command Line Interface (CLI) 	
	Date and Time Screensaver 	
	Digital Inputs 	
	iTunes 	
	MoodLogic 	
	MusicMagic 	
	Network Test 	
	Podcasts 	
	Random Mix 	
	Real Rhapsody 	
	Rescan Music Library 	
	RS232 	
	RSS News Ticker 	
	Save Playlist 	
	SlimTris 	
	Snow Screensaver 	
	Visualizer Screensaver 	
	Windows: Prevent System Standby While Playing 	
	XML-RPC/JSON-RPC Interface 	
	xPL Interface

I don't see anything related to power save?

Nope I had missed the forum discussion.  Thanks for pointing it out.  I appreciate the log files, but in this case they don't seem to point to a single obvious problem, so I'd like to focus on trying to reproduce the problem.

Is it only affecting Windows users?  Are there any non-Windows users seeing this bug?

What state is the PC in when this shows up?  Has it been powered off?  Hibernating (S4 in pc jargon)?  Sleep or 'standby'?  Or just powered on the whole time?

Also, Dan recently added some code to allow the user to select whether to 'Automatically run at system start' OR 'Automatically run at login'.  This is set on the system tray icon for Slimserver.  What setting do people have for that option?

Thanks for the info!

I experienced the problem when I upgraded the firmware in my LinkSys WAG54GX2 (Firmware Version: V1.00.09), and
the Squeezeboxes were connected via DHCP allocated by the router.

For the record, I am currently not experiencing the problem since configuring my boxes to use static IP addresses.

I am running on WinXP Pro.  I was running SlimServer 7.0 trunk (can't tell you what SVN number).
I tried downgrading to 6.5.1 and had the same reconnection issue.

I don't using the tray icon app at all - I run a windows service that starts slimserver interpreted using ActivePerl.

Chris, this in response to your query.

Using Windows XP.

PC state is powered on the whole time.

System tray settings: Automatically run at system start. 

I have not experienced this problem for over a week. The only "changes" I have made is to leave the SB3 powered up at all times (as opposed to previously powering down the power conditioner to which the SB3 was connected when the SB3 was not in use) and swapped out the Cat 5E cable (had tried two other cables which made no difference) from the Netgear homeplug to the SB3. 

Keeping my fingers crossed that it won't happen again. 

This has been continuing to happen to me since I got the SB last week (been playing with it a lot since then).

I'm running Windows XP SP2, running SlimServer as a service.

Both if the server is stopped, and restarted, or the SB is turned off and left off for awhile (I don't know the specific delay that will trigger it, if there is one, but at least 20 mins), then turned back on -- I see this happening.

I reported this in the forums, and it was suggested I press the 'power' button over and over to try to get the SB to connect, and if that didn't work, restart SlimServer, then do the power-button-pressing routine again.

It didn't work right away.  I tried that, and after the 3rd or 4th "Waking up SlimServer" and "Connecting" didn't do anyway, I walked away.  When I came back (about 5 mins later) and pressed 'power', THEN it was connected.

Something's taking an awful long time to connect there. :-(

My router is a LinkSys WRT54GL running the latest Sveasoft Talisman firmware (no problems with it anywhere else so far), using WPA2/AES.  My software firewall on the server machine is showing the connect attempts, and SlimServer *seems* to be responding (can't tell just from the log), but the SB doesn't think it's connected, and SlimServer doesn't think it is, either.

- Tim

Please try the latest firmware (squeezebox 69 / transporter 24) that will be in the Nov 22 nightly slimserver 6.5.1 release. This fixes a dhcp bug that could cause connection problem with the firmware.

I should have mentioned, by the way, that I'm using a static IP in this setup, so DHCP doesn't come into it.

- Tim

(In reply to comment #43)
> Please try the latest firmware (squeezebox 69 / transporter 24) that will be in
> the Nov 22 nightly slimserver 6.5.1 release. This fixes a dhcp bug that could
> cause connection problem with the firmware.
> 

I have installed this and so far, there is a distinct improvement. It has been less
than 24 hours, but so far it has not lost the connection at all, whereas it would
previously go out several times per day, often for hours, with no reliable means of
reconnecting.

I will advise with more data later.

I have installed this firmware / SlimServer combination, and am having the exact same problems I did before. Nothing has changed, and I still lose connectivity regularly.

I will report back if I notice this not happening as frequently, however.

- Tim

(In reply to comment #46)
> I have installed this firmware / SlimServer combination, and am having the
> exact same problems I did before. Nothing has changed, and I still lose
> connectivity regularly.
> 
> I will report back if I notice this not happening as frequently, however.
> 
> - Tim
> 

Disappointed to report, alas, that the problems continue for me too, although less frequently.

It also seems that at least relatively consistently I can re-establish the connection by re-trying.

- Greg

Is anyone ever going to rigorously try to track down and fix this one?

- Tim

I haven't forgotten about this bug.  The problem with fixing it 'rigorously' is still that I haven't been able to reliably reproduce it here.  With both transporters and squeezeboxes I've tried playing for extended periods, turning the units 'off' and leaving them for extended periods, disconnecting the power many times, and shutting down and restarting slimservermany times, and although I have seen occasional misbehavior, I can't reproduce it well enough to be able to say it is the same bug you are reporting.

Is everyone who is experiencing this bug connected via a wired or wireless connection?

(In reply to comment #49)
> I haven't forgotten about this bug.  The problem with fixing it 'rigorously' is
> still that I haven't been able to reliably reproduce it here.

[ snippage ]

> Is everyone who is experiencing this bug connected via a wired or wireless
> connection?

I'm using it wirelessly only, on a G-only network, using WPA security.
Signal strength is pretty much always 30% or above.

I have a software firewall on the slimserver machine, but it's got the
requisite ports open (although I can't remember if I specifically opened up
the web interface to the SqueezeBox -- only the control ports need to be
open, correct? Or are you using port 9000 somehow to ping that the
server's alive, as well?).

- Tim

By the way, sometimes the Squeezebox loses connectivity with the server in the middle of playing a song, as well, though that happens infrequently.  When that happens, I have to go through the wireless setup again, as with THIS bug, as well.

- Tim

The web port, 9000, is also used for streaming any local audio files to the player.  I assume this is working for you, but you may want to disable your firewall completely and see if things improve.

I think it's important to make sure that anyone reporting this problem is not experiencing some other issue, such as firewall, networking, DHCP, or wireless problems.  I know that's often difficult, but you can't have a bug that encompasses 100 different issues.  Enabling logging on the server may be the only way to tell for sure.

I'm no longer experiencing the problem for whatever reason, but as the logs I posted above show, the original bug was when the SBs on the network and/or SlimServer got stuck in some sort of loop while negotiating the connection.  I never experienced a loss in connectivity.  My guess is that it was the server software getting stuck in a loop, rather than a bug in the firmware on the Squeezeboxes.

(In reply to comment #52)
> The web port, 9000, is also used for streaming any local audio files to the
> player.  I assume this is working for you, but you may want to disable your
> firewall completely and see if things improve.

Are you saying that the web port is used to stream files from the server to the player, or for me to direct the server to load a file I direct it to, to the player?

If the 1st, I should open up that port to the player.

If the 2nd, I haven't used that feature.

I'd be willing to turn off the firewall... I *have* noticed enough suspect packets that get inside my network from outside, despite my wireless router and DSL modem both having some firewall capabilities enabled, that I'd be slightly concerned about instrusions (I'm a security freak :-) ), but I'll give it a try, since I can reproduce it pretty easily.

I'll let you know if turning off the software firewall has any effect.  Looking at the packet log, it *appears* that EVERY packet from the player is getting through... could be some broadcast packets that don't *appear* to come from the player, actually ARE from the player, and are being filtered out.

- Tim

9000 is used when the player needs to get any sort of audio data from SlimServer.  The ports you need to have open are 3483 UDP/TCP and 9000 TCP.

I'm seeing this issue too, and may be able to shed some light on it.

I'm using an SB3 (firmware 71) connected wirelessly via a Belkin AP, and obtaining an IP address via DHCP.  I'm running SlimServer Version 6.5.1 r11024.

Periodically, I believe always after a server start, the Squeezebox will go blank and refuse to connect.  It will flash up 'Connecting to SlimServer...' for a few seconds, then go blank.  Attempts to connect to Squeezenetwork show exactly the same symptoms, so I think that discounts SlimServer as being at fault.

The problem is remedied by power cycling the Squeezebox, whereupon it connects immediately.

I've captured a sequence of packets (attached) on the machine running slimserver, and this also seems to point to a firmware issue.  The log shows a burst of SliMP3 discovery requests, agreeing with the contents of the previously posted logs.  There is then a burst of repeated ARP lookups for the MAC address of the machine running slimserver, which are logged as having been answered, but seem to get lost or are ignored by the Squeezebox.

Could this be the problem --- that for some reason, the squeezebox is missing the ARP responses for the SlimServer machine (and presumably the gateway required to access the internet for Squeezenetwork)?


Richard, is there any chance of adding some debugging to the Squeezebox firmware, such that it stores up any errors, ready to spit out to slimserver for logging after the next successful reconnect?

Created attachment 1747 [details]
Packet capture showing Squeezebox failing to reconnect

It would be useful to know what was happening during this packet trace (e.g. around what time did you restart the slimserver, reboot the squeezebox, etc).

Packets 2-184 are all slim discovery / ARP packets. The squeezebox does try to connect to the slimserver at packet 185, but it appears the tcp handshake does not complete. I'd say you rebooted the squeezebox at packet 195, and then the connection starts correctly.

What version/firmware Belkin AP are you using, this could be a wireless re-connection issue we are seeing here.

I would also say this is a different problem from the one originally posted, which is almost certainly a slimserver problem as it also occurs with Softsqueeze.

Jim (and others), do you still see this? If so could you be able to capture a packet trace for comparison?

Thanks,
Richard

(In reply to comment #58)
> It would be useful to know what was happening during this packet trace (e.g.
> around what time did you restart the slimserver, reboot the squeezebox, etc).
> Packets 2-184 are all slim discovery / ARP packets. The squeezebox does try to
> connect to the slimserver at packet 185, but it appears the tcp handshake does
> not complete. I'd say you rebooted the squeezebox at packet 195, and then the
> connection starts correctly.

The log starts when the SB is showing the described behaviour -- i.e. blank display and won't connect.  I tried about 5 times to connect to SlimServer, and a couple of times to connect to SN, although these don't show up in the log.  The SB was then restated, and a small amount of menu activity conducted.  I can't say whether the failed tcp handsake was before of after the reboot I'm afraid, I didn't leave the power off for long enough.

> What version/firmware Belkin AP are you using, this could be a wireless
> re-connection issue we are seeing here.

I'm using 128bit WEP with a Belkin wirelss router (F5D7632v1.UK.1.00.09 (Jul 13 2005 19:14:46)) and a Belkin AP, (F5D7230-4, FW 4.05.03), which are wired together.  The SB is significantly closer to the AP than the router.

> I would also say this is a different problem from the one originally posted,
> which is almost certainly a slimserver problem as it also occurs with
> Softsqueeze.

Somewhere, the comment was made that there appeared to be two differrent bugs being described, and these symptoms did seem quite close to some of those described.  Do you want to split this off into another bug though?

I'm seeing a lot of this now - don't know why or what's changed.  I'm at latest 6.5.1/Firmware 71 but I saw it with 69.

The most common version:

The SB3 is off for a while, and the screen goes blank.  If I press power on, I see waking up slimserver, connecting to slimserver, then back to black.  I've got d_slimproto denabled, and see nothing in the trace.

If I hold the power button down, then before the time it takes to get to the soft reset, the SB3 reconnects and goes into its power on state.

In the trace, before the reconnect I see:

Haven't heard from 00:04:20:06:3e:0a in 15 seconds, closing connection
Slimproto connection closed
Slimproto - forgetting disconnected client

When the SB3 is in this state, I can ping it.

To confuse things, I also saw one case in which the SB3 could NOT be pinged, and was not responding to arp broadcasts.

On other thought.  My setup has uncertain wireless connectivity.  I've always suspected that there were flaws in recovery from lost packets.

Created attachment 1765 [details]
Packet capture showing Squeezebox failing to reconnect v2

This was captured from a wirelessly connected laptop whilst a wirelessly connected squeezebox fails to connect to slimserver or squeezenetwork.  Hardware is all as described in Comment #59.

Initially, several attempts are made to connect to slimserver and squeezenetwork, all failing.  After a while, the SB manages to connect to slimserver, but still fails to connect to SN.

The SB is then power cycled, and immediately connects to SN and slimserver.

Combined with the previous packet captures, this seem to suggest that the problem is caused by the ARP response packets failing to get through to the SB until after it is power cycled.  Any thoughts on what might be causing this.

Here are my own results...

I ran Ethereal (well, Wireshark) with 3 different scenarios.  I also unplugged any other devices I had connected to make sure there was as little traffic as possible.  The IPs and MACs are as below.  Perhaps this will help diagnose the problem? It LOOKS like the same symptoms Christopher was having (tho' I'm not a network expert):

192.168.1.101 / 00:13:20:09:de:cd (IntelCor_09:de:cd) : The computer running SlimServer
192.168.1.150 / 00:04:20:06:db:3d (SlimDevi_06:db:3d) : Static IP / MAC for my SqueezeBox
192.168.1.1 / 00:18:39:c1:84:b0 (Cisco-Li_c1:84:b0) : My Wireless Router

1) SlimServer is on, my SqueezeBox is plugged in but off, and I press the "On" button on the SqueezeBox (I get the "waking up" and "connecting" messages on the SqueezeBox, but it does not connect, and goes blank.  I press "On" again, and the same thing happens.
( [url]http://www.sonic.net/~tbessie/misc/capture-squeezebox-onbutton-2x.html[/url] )


2) SlimServer is on, my SqueezeBox is plugged in but off, and I do nothing but capture (no pressing of buttons)
( [url]http://www.sonic.net/~tbessie/misc/capture-squeezebox-nopush.html[/url] )

3) SlimServer is on, my SqueezeBox is plugged in but off.  I press "On", get the "waking up" message, but press "back", go to "set up networking" and run through the menus, the SqueezeBox restarts, connects to the network again, I press "forward" until I the SqueezeBox AGAIN goes blank. Then press "On", and the SqueezeBox connects to SlimServer.
( [url]http://www.sonic.net/~tbessie/misc/capture-squeezebox-on-reset-on-connect.html[/url] )

Whoops! Let me correct those URLs for you...

http://www.sonic.net/~tbessie/misc/capture-squeezebox-onbutton-2x.html

http://www.sonic.net/~tbessie/misc/capture-squeezebox-nopush.html

http://www.sonic.net/~tbessie/misc/capture-squeezebox-on-reset-on-connect.html

I'll also attach these as capture files here.

- Tim

Created attachment 1770 [details]
Packet capture - SB is off

Created attachment 1771 [details]
Packet capture - SB is off, press on, no connect, press on again, no connect

Created attachment 1772 [details]
Packet capture - SB is off, press on, no connect, press back, go through net menu, restart, press on, connects

The latest traces from Christopher and Tim do both show arp problems, but in one case the SB is not getting an arp response from the server and in the other the server is not getting an arp response from the squeezebox. Unfortunately these traces don't give any indication that I can see why things have gone wrong.

What events lead up to the Squeezebox not connecting? The original bug report was about restarting slimserver, is this still the case? Do you just restart slimserver or the whole PC? If it's the PC has it been turned off for any length of time? Is this an issue for wired and wireless networks? Does this just happen with slimserver on windows, has anyone on OSX or Linux seen this? What firewalls are you running, does disabling the firewall help? Can Softsqueeze connect to the slimserver at this time?

If this is a firmware issue (and that's still not 100% clear) it would be useful to be able to know when the problem started occurring. I could then review the changes made in that firmware release.

Any information that will enable me to recreate this problem here would be most helpful.

Thanks,
Richard

(In reply to comment #68)
> What events lead up to the Squeezebox not connecting?

In my case, the machine running SlimServer is on, and I have
gotten the SB to connect (sometimes required a reset, going
through the network menus, etc.).  Then, after using the SB
for awhile (or not), I turn the SB "off".

Some time later, without the machine running SlimServer having
changed state (no rebooting, putting to sleep, etc.), I turn the
SB "on", and it is in this state.  SlimServer has not been restarted
and the machine it's on has not been restarted... nothing on that
machine has changed.

When in this state, I get the "waking up SlimServer" and "connecting"
messages on the SB, and I must go back, through the network menus again
(going through all the settings, so that the SB restarts and reconnects
to the network anew), and then press "on" again, for the SB to connect
to SlimServer again.

> The original bug report
> was about restarting slimserver, is this still the case? Do you just restart
> slimserver or the whole PC? If it's the PC has it been turned off for any
> length of time? Is this an issue for wired and wireless networks? Does this
> just happen with slimserver on windows, has anyone on OSX or Linux seen this?
> What firewalls are you running, does disabling the firewall help? Can
> Softsqueeze connect to the slimserver at this time?

This is running SlimServer on an XP Pro machine, connecting the SB
to SlimServer wirelessly, I'm using WPA2 for security, I have a software
firewall running on the SlimServer machine (Sygate), but all packets coming
from the SB's MAC are allowed.

I have done this with Sygate turned off (no software firewall), and I *still*
get this problem, so I don't think it's that.

> If this is a firmware issue (and that's still not 100% clear) it would be
> useful to be able to know when the problem started occurring. I could then
> review the changes made in that firmware release.

It's been this way forever for me, ever since I bought and configured my SB.

> Any information that will enable me to recreate this problem here would be most
> helpful.

Hope this helps. :-)

- Tim

I was only seeing the problem when I shut down Slimserver (to do an SVN update) and then restarted Slimserver.
The squeezeboxes would not automatically redetect Slimserver; even if I power cycled the SB.  But I found that if I pressed power button twice quickly the box would reconnect and all would be fine until I restarted Slimserver again.

The problem went away when I went through the whole SB configuration setup entering everything again manually.  I changed from dynamic IP address allocation to static addresses at the same time.  I haven't had a problem with reconnections since.

I see the same progression.  Usually, I notice in the morning that the clock display is blank.  Note that this normally happens to one of my two SB3's and the other is fine.

If I press power on quickly, I get the reported behavior.  Often, if I hold power on for 1-2 seconds (not enough for a reset) it then connects correctly.  Others might try that.

(In reply to comment #70)
> I was only seeing the problem when I shut down Slimserver (to do an SVN update)
> and then restarted Slimserver.

Yeah, that wasn't the case with me.

> The squeezeboxes would not automatically redetect Slimserver; even if I power
> cycled the SB.  But I found that if I pressed power button twice quickly the
> box would reconnect and all would be fine until I restarted Slimserver again.

That is not the case with me.  The ONLY way I can get it to
reconnect is to go through the entire network connection menu set,
then the SB resets, tries to connect to the network again, the screen
then goes blank, and THEN when I press "on" it is connected.

> The problem went away when I went through the whole SB configuration setup
> entering everything again manually.  I changed from dynamic IP address
> allocation to static addresses at the same time.  I haven't had a problem with
> reconnections since.

I'm already using that setup (everything's static), and I still have the problem.

- Tim

(In reply to comment #70)
> I was only seeing the problem when I shut down Slimserver (to do an SVN update)
> and then restarted Slimserver.
> The squeezeboxes would not automatically redetect Slimserver; even if I power
> cycled the SB.  But I found that if I pressed power button twice quickly the
> box would reconnect and all would be fine until I restarted Slimserver again.
> The problem went away when I went through the whole SB configuration setup
> entering everything again manually.  I changed from dynamic IP address
> allocation to static addresses at the same time.  I haven't had a problem with
> reconnections since.

My situation was similar, the problem arose whenever SlimServer was restarted (the service, not the machine), except that I'm using dynamic DHCP addresses.  Running SlimServer Perl as a service on XP Pro with two wireless SB2s.  Never have used a firewall on the server.  The problem also went away for me, in early September, as mentioned above in comment #24, shortly before 6.5.0 was released.  No idea what changed at that time.

(In reply to comment #73)
> My situation was similar, the problem arose whenever SlimServer was restarted
> (the service, not the machine), except that I'm using dynamic DHCP addresses. 
> Running SlimServer Perl as a service on XP Pro with two wireless SB2s.  Never
> have used a firewall on the server.  The problem also went away for me, in
> early September, as mentioned above in comment #24, shortly before 6.5.0 was
> released.  No idea what changed at that time.

I'm running the nightly build.

- Tim

As I posted in comment #32:

Pretty much 100% reproducible on my system as:  "..when I turn the computer on,
SB does not start automatically; and it is not detected in the SS web
interface. When I press the 'Power On' button on the remote, the SB screen says
that it is 'connecting to slim server' and then that it is 'waking up slim
server'. The screen then blanks again. Many more presses of the Power On button
usually gets the SB connected to SS."

This still exists for me.  By the way, when this does happen I cannot get to the SS web interface either.

DEFINITELY started when I went to 6.5.x, was never there before.

- Bruce

Is everyone that's seeing this problem running XP?  Are all the squeezeboxes connected wirelessly or are some wired?  What routers are people using?

(In reply to comment #76)
> Is everyone that's seeing this problem running XP?  Are all the squeezeboxes
> connected wirelessly or are some wired?  What routers are people using?

1. Running XP Pro with all the latest updates
2. Squeezebox connected wireless (WPA2)
3. Router is LinkSys WPR54GL v. 1.1, running the latest Sveasoft 3rd party router software for it.

- Tim

Running Win XP Pro, latest service pack and updates
Linksys WRT54g
Wireless, uing DHCP for ip addressing
Happens with both SB2 and SB3 , but it *seems* the SB2 is more prone to it.

Slimserver on WXP Home SP2 (almost latest 6.5.1)
Two SB3 Firmware 72 both see the problem
Wireless with 128bit WEP, Fixed IP addresses
Linksys WRT54G V2 with latest Linksys Firmware running in B mode

Win XP Pro
Linksys WAG54GX2 Firmware Version: V1.00.09
Wireless WPA-Personal, TKIP.

I think there are probably a couple of different issues being detailed here, and one probably merits a new bug report.  My problem is definately not SlimServer related; the SqueezeBox would also refuse to connect to SqueezeNetwork too.

It happened fairly frequently, every few days, and has been a problem as long as I've had my SqueezeBox (since April 2006).  The SqueezeBox display would be blank, and would refuse to connect to either SlimServer or SqueezeNetwork.  After several attempts, it would usually manage to connect to one of the two, but the other would still fail.

My current suspicion is that it is a wireless issue, although I'm not sure whether the fault is with the access points or the SqueezeBox.

Unfortunatly, I can't perform any more diagnostics, as I've changed setup somewhat now. I'm in a different location and no longer connected wirelessly.  The problems have so far disappeared.

However, I did manage to perform a simultaneous packet capture from a wireless laptop and from the machine running slim server, which I'll attach shortly.

Created attachment 1775 [details]
Packet Capture from SlimServer Machine

Created attachment 1776 [details]
Packet Capture from (wireless) Laptop Machine

(In reply to comment #76)

WindowsXP Home SP2, all updates.

Wireless via Belkin F5D7230.  802.11g, WEP 128, fixed IP.

No wireless connectivity issues with any other devices, and no issues with this router before 6.5.x

- Bruce

This is still occurring in the latest versions of 6.5.2.
Shall we change the "Version" in this bug to match?

- tim

Yes if people are still seeing this in 6.5.2 I will update the version.

So are people still seeing the same symptoms as originally reported?  That is, if you shut down the service for a period, and then restart it, the Squeezebox will not reconnect?

(In reply to comment #86)
> Yes if people are still seeing this in 6.5.2 I will update the version.
> 
> So are people still seeing the same symptoms as originally reported?  That is,
> if you shut down the service for a period, and then restart it, the Squeezebox
> will not reconnect?

I haven't tested that, but I know for certain that the SqueezeBox becomes
unable to talk to SlimServer at random times, and that also if I restart
my computer or bring it out of a sleep, I need to restart the SqueezeBox
for it to be able to connect.  That is probably functionally equivalent to
the above scenario.

I am always using the latest 6.5.2 release and firmware.

- Tim

I still see this randomly with firmware 80.  I have two SB3s.  Often, on connects and one doesn't.  Not the biggest deal.

And it still takes two pushes on the power button to get it to connect.

We haven't done enough on this bug for any fix to go in to 6.5.2.

Is this still an issue with SC7?

Ping again: Is this problem resolved for folks with SqueezeCenter 7.0?

For me its working OK (SB3, SC7), I havent experienced this in a long while.
(Note: my connection schema changed since one year ago, I used to have the computer with SC connected wirelessly to the network back then, now its ethernet-conected)

I am using the latest version of SqueezeCenter 7, and I'm still getting this problem.  The SqueezeBox still doesn't usually connect after being off for awhile, and I have to restart it for it to work.  Also, it loses the connection on average about once every hour or so... the screen just goes blank, and pressing the power button just brings up "Waking up SqueezeCenter" and "Connecting to SqueezeCenter", but nothing happens, and I have to restart the device again.

Ross, do you think this might be bad hardware?

I *do* wonder if I just have a bad unit.  Though I'm able to connect to Slim Devices' server without fail and without the need to restart.  It might be particular router configurations/hardware/firmware that make this happen, but it's only with my SqueezeBox that I have any network issues at all.  I wish we could figure out what's happening here.

Tim would you like to try another unit? We can RMA if you'd like?

That's very kind of you, Ross; I wouldn't mind, if it's not a lot of trouble, if only because then we can be reasonably sure if it is a problem with the device, or with my router/firewall setup (and that of others who have this rare problem).

How would we go about this? I've had the unit for quite awhile, so don't have the packaging anymore.

Thanks Tim, Julius from support can help us get you a new Squeezebox to try. Don't worry about packaging we'll take care of the details, thank you again for working with us on this! You'll receive an email from Julius later today. 

Ross/Chris...

So I received the new SB3 yesterday, and tried it out last night.
Same problem, so no joy. :-(

I'll do some more experiments and report back here.  I rebooted my
router once to see if the SB was once again able to connect, and it was,
but I didn't try other experiments yet.

I also tried both using the static IP I'd been using, and a static IP
linked to DHCP on the router; both had the same problem, in which the SB
just suddenly lost connectivity in the middle of playing, so IP assignment
didn't have anything to do with it, apparently.

It's very strange, because no other networked device I use has this
problem.  When I was using my old Roku Soundbridge via WPA2 (I'm using WPA2
security now, too), I never had this problem, and when I've used my
laptop wirelessly, also no problem.  I'm wondering if it has something
to do with the SB firmware's IP stack, something to do with negotiation.
I remember this happened even when I was using WEP, so I don't think it has
anything to do with the security being used from what I could tell.

Do you know if the SB's IP stack has any nonstandard or incomplete, or
particularly non-fault-tolerant algorithms in it?

- Tim

Hello all

I fixed a wireless key (GTK) renewal issue in firmware which prevented a player from receiving broadcast packets properly after a while. This might have been the cause of some of the reconnection issues reported here.
The bug fix will be in SB fw 86, TR fw 36 and SBR fw 21.

Hello Felix...

This *sounds* like it could be the problem; I remember packet traces showing
problems with the player receiving broadcast messages, I think (it's in the history of
this bug somewhere).

When will this firmware be released, do you know?  Is it in the nightlies
for 7.0 now?

- Tim

Hi Tim, it should be in tomorrow's nightly build.  Let us know how it goes!

(In reply to comment #102)
> Hi Tim, it should be in tomorrow's nightly build.  Let us know how it goes!

Chris...

Since I got that build and updated the firmware, I am no longer getting random disconnects or inability to connect upon startup, as before.  This seems to have solved the problem!  Hip-hip hooray! :-)

If you don't mind my asking, how was this bug discovered?  Seems to have been lurking there for awhile - was it an obscure problem?

- Tim

By the way, I just noticed that sometimes, with this latest release, I have to kill and restart SqueezeCenter, as it appears to get hung somehow (when I tell the SB to play something, it says it's playing it, but it doesn't play, for example).  Also, the SB hangs sometimes when doing simple things when scrolling through albums.

- Tim

(In reply to comment #104)
> By the way, I just noticed that sometimes, with this latest release, I have to
> kill and restart SqueezeCenter, as it appears to get hung somehow (when I tell
> the SB to play something, it says it's playing it, but it doesn't play, for
> example).  Also, the SB hangs sometimes when doing simple things when scrolling
> through albums.

Correction: When I restart SqueezeCenter, this doesn't help.  The SB says "Connection Timed Out" when I try to play something.  Rebooting the router and unplugging/replugging the SB has no effect.  I shall now try rebooting my server computer. :-(

- Tim

(In reply to comment #105)
> (In reply to comment #104)
> > By the way, I just noticed that sometimes, with this latest release, I have to
> > kill and restart SqueezeCenter, as it appears to get hung somehow (when I tell
> > the SB to play something, it says it's playing it, but it doesn't play, for
> > example).  Also, the SB hangs sometimes when doing simple things when scrolling
> > through albums.
> 
> Correction: When I restart SqueezeCenter, this doesn't help.  The SB says
> "Connection Timed Out" when I try to play something.  Rebooting the router and
> unplugging/replugging the SB has no effect.  I shall now try rebooting my
> server computer. :-(

Okay, nevermind on that - I hadn't updated my software firewall with the MAC address of the new SB you folks sent me.  I did that and it seems to be working again.  Can't say why the firewall was allowing packets before; I may have rebooted the server in between.

Anyway, I will report back here if I see any strange behavior, but I'm thinking it is, indeed fixed.  Thanks!

- Tim

Appears fixed.  Reopen if it's still an issue for you.

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.