PDA

View Full Version : Newly installed 7.1 behaving maddeningly



glashoppah
2008-08-05, 18:55
I've had Squeezebox/Slimserver for a while and have been quite happy, which means my wife has been quite happy with it. Last week my server took a dump, and I rebuilt the OS drive (the data drives were unaffected). Yesterday I reinstalled Slimserver on it, first downloading the latest version (7.1). Slimserver then updated my Squeezebox to the latest firmware. I pointed Slimserver to my shared music folder and to its original shared playlist folder. All looked normal. The Squeezebox jumped right on the server and displayed normally. I didn't try to play any music with it, knowing my wife would soon test it completely.

Tonight we tried it. Fail. It plays exactly 60 seconds of a song (whatever song we select) and then repeats it - the same 60 seconds. Just try to listen to the first 60 seconds of any song 20 times and see if you don't subsequently want to run an icepick into your own ears.

There are a number of other symptoms of whatever problem this is:

1. Any selection of a new song doesn't take effect until the 60-second "window" passes.
2. Any selection of a new volume level, or "pause", or any other setting, doesn't take effect until the same 60-second "window" passes.
3. When a new song is selected, it too then plays for 60 seconds and repeats, presumably forever.

I counted myself pretty competent with Slimserver. I see no settings that are out of the ordinary. I've tried disabling the service, but this does not stop the player from repeating 60 seconds of whatever it's playing ad infinitum.

This may be of help. This is repeated in the log every minute:

[08-08-05 18:52:53.1299] Slim::Networking::SqueezeNetwork::PrefSync::_syncD own_error (354) Sync Down failed: No such player: 00:04:20:07:9e:49, will retry in 12480
[08-08-05 18:53:53.1363] Slim::Networking::SqueezeNetwork::PrefSync::_syncD own_error (354) Sync Down failed: No such player: 00:04:20:07:9e:49, will retry in 12510
[08-08-05 18:54:53.1502] Slim::Networking::SqueezeNetwork::PrefSync::_syncD own_error (354) Sync Down failed: No such player: 00:04:20:07:9e:49, will retry in 12540
[08-08-05 18:55:53.2096] Slim::Networking::SqueezeNetwork::PrefSync::_syncD own_error (354) Sync Down failed: No such player: 00:04:20:07:9e:49, will retry in 12570

Please help. Wife is looking very upset.

G.

maggior
2008-08-05, 20:17
Can't say I've heard of this behavior before. An icepick indeed! :-).

You mention "service", so we are talking Windows?

You didn't have this problem before you reinstalled the OS. Can you think of any configuration changes you had to make when you set up initially that you may have forgotten? Anti-virus? Firewall?

Static IP? Perhaps you set the IP address incorrectly and now have a conflict with another device on your network? Specifically the IP address of the server. Did you change the IP of the SB? Might want to check that too.

The first thing I would do is disable AntiVirus and any firewall and see what the behavior is.

Details will also help:
Wired or Wireless?
OS Version?
SB3/Duet?

glashoppah
2008-08-05, 20:24
The server's OS is Win2003, same as before. It basically has nothing running on it. SlimServer is v7.1. It's a fresh install of SlimServer, with no restore of any backed up data. The Squeezebox probably has a different IP since the server is also the DHCP server for the network and its' DHCP table was blown away. There are no firewalls or anti virus processes running. Yes, when I refer to the service, I'm talking about the SlimServer service on the 2003 server.

The Squeezebox is operating wirelessly to a G AP.

G.

maggior
2008-08-05, 20:39
I'm not a DHCP expert by any means, but is it possible that you have devices on the network that are using addresses assigned to it prior to rebuilding the box and these addresses now conflict with addresses that the new server is handing out?

If this were the case, I would think restarting the other devices on your network would clear that up.

I can't think of anything else off hand...

glashoppah
2008-08-05, 20:51
I'm not a DHCP expert by any means, but is it possible that you have devices on the network that are using addresses assigned to it prior to rebuilding the box and these addresses now conflict with addresses that the new server is handing out?

If this were the case, I would think restarting the other devices on your network would clear that up.

I can't think of anything else off hand...


That is a very good thought, one that would explain a lot of wierdness. I'll give it a shot. I have a lot of network gear. Time for some reboots.

G.

glashoppah
2008-08-05, 21:30
I'm not a DHCP expert by any means, but is it possible that you have devices on the network that are using addresses assigned to it prior to rebuilding the box and these addresses now conflict with addresses that the new server is handing out?

If this were the case, I would think restarting the other devices on your network would clear that up.

I can't think of anything else off hand...

This was exactly the problem. It seems to work flawlessly now. I had three access points that got their IPs automatically that weren't refreshed, and one was conflicting.

Thank you very kindly.

I'm kinda pissed at myself, seeing that I do this networking stuff for a living. Of course, us network folks always look to the app first.... :)

G.