Bugzilla – Bug 3591
Flakiness recognizing multiple Slim Servers on network
Last modified: 2009-09-08 09:23:14 UTC
I just installed the latest 6.5 trunk on my server. I'm still running the pre-merge 6.5 on the same server, but on a different IP address. The machine name is "audrey" and both SlimServers are listening on the standard CLI port 3483. 6.5 r7499 on 192.168.9.3 6.5 r8023 on 192.168.9.4 I upgraded the SB2 to firmware 54 by copying it to the r7499 directories and then rebooting that server. After the SB2 firmware upgrade it rebooted and automatically connected to the old server at 192.168.9.3. I then power cycled the SB2 to see if it could see the second server. It does... sort of. On my 'Select a music source' screen in the setup I see three selections. (1 of 3): audrey (192.168.9.3) (2 of 3): Specify an IP address for your SlimServer (3 of 3): Connect to SqueezeNetwork But if I let it sit on that selection #1 long enought the display actually flips back and forth between the two IP addresses. Not having run two servers on my network before, I'd assume that they're supposed to show up in the list as individually selectable items. I suppose this could be an imcompatibility between firmware 54 and r7499, or perhaps nobody has ever run two instances of SlimServers on the same machine, same port, but different IP addresses.
I've seen something similar where a server disappears but it's name stays in the list (which is expected if it was the last server you connected to) BUT if you try to connect to it you connect to another discovered server on the network. I'd bet it's related. Richard: is this behavior familiar to you?
I went back to firmware 48 and it behaves the same as 54 when both SlimServers are running. One other thing I noticed with both fw versions. Perhaps this is a result of the SB thinking there's only one SlimServer on the netowrk. When you hold down the left arrow to go back into the topmost setup screen, the menu item (this time 4 of 4) always just shows a plain "Connect to audrey" with no mention of IP address. I have to go through the entire network setup, making no changes, and reconnecting to the wireless network, before I see the IP address which flips between the two servers.
richard: did you look at this yet?
Fixed in squeezebox firmware 55. This is now in test.
Sorry wrong bug, I've not fixed this at all yet! Actually I'm having problems recreating it on my server, see my post in the unix forums.
This bug now contains three issues: 1) If you have two slimservers running on one server but using different IP addresses then the server hostname broadcast in the discovery packets is the same. In the setup menus the firmware will flips between these IP addresses making it difficult to select the correct server. Having looked at the code the firmware is working as intended, so for now I think this is invalid. The assumption is that each server is uniquely named, and therefore it's IP address has changed. I think this issue would be better resolved by fixing bug 3592 allowing slimservers to be named. 2) If a slimserver disappears then selecting it in the setup menu connects to another slimserver on the network. dean - I cannot recreate this, detailed steps would be good. 3) Inconsistant naming between the "Select a music source", "Current Settings" and main menus for the slimserver. I will fix this so the server always appears in this format: "hostname (1.1.1.1)"
I think 3592 would be a good thing (I filed the request), but it shouldn't be necessary to fix this if you're uniquely identifying the servers using "hostname (ipaddress)". That would solve both 1 & 3, instead of treating 3 as only a user interface issue. What about unique ports? Is it possible to run two instances of SlimServer on the same IP address, but different ports?
1) We have resolved to move ahead with 3592 as the right way of fixing this. 2) split off to bug 3967 3) Are you still working on this consistent name/IP display issue, Richard? Or is that done?
The consistent name/IP display issue was fixed in firmware 58 or 59 (cannot remember exactly which).
Today I revisited this problem and have begun testing the ability to run multiple instances of SlimServer on a single Windows machine. I still get that "IP address flips back and forth" behavior on the Squeezebox2 when presented with the server selectiong in the Squeezebox setup. This time around it's possible to select one or the other, and the Squeezebox is able to connect to the selected server, but the flipping-back-and-forth bit is still a bit sketchy. Is this the expected behavior?
(In reply to comment #6) > This bug now contains three issues: > 1) If you have two slimservers running on one server but using different IP > addresses then the server hostname broadcast in the discovery packets is the > same. In the setup menus the firmware will flips between these IP addresses > making it difficult to select the correct server. > Having looked at the code the firmware is working as intended, so for now I > think this is invalid. The assumption is that each server is uniquely named, > and therefore it's IP address has changed. I think this issue would be better > resolved by fixing bug 3592 allowing slimservers to be named. My contention is still that there's something wrong here. The assumption about unique server names is obviously flawed. Why can the firmware not use the IP address instead of the server name when determining servers from which to choose? The display could remain exactly the same, but it would present a list such as: Connect to myserver (192.168.1.4) Connect to myserver (192.168.1.5) Connect to myserver (192.168.1.6) Changing the logic within the firmware would seem more straightforward than all hair pulling that it will take to get bug 3592 implemented as a new server pref.
One issue is that on a DHCP network, servers often change IP address while keeping the same name. This is a common case. How would we handle this?
Good point. I've never run SlimServer on a dynamic IP address, but I assume that the SB firmware uses the name to seamlessly reconnect to the same server on the network. Then how about using name+ip to identify servers instead of one or the other? The 'automatic reconnect' routine could try to find name+ip among the list of servers it sees, then fall back to just name (with any ip). If there's more than one server with the same name, which do you choose? It doesn't matter - it's going to be a different server - either select one or force the user into setup to choose one (which is, intended or not, the current behavior). I wouldn't expect anyone to be using DHCP for a machine running multiple SlimServers instances. The only twist to this logic that I'd recommend is having a wait/timeout period whenever the connection to the current server is lost and doesn't immediately reappear, but there is another server in the list with the same name. That way you can have multiple servers at the same name and be able to restart one without having the SB latch on to one of the others.
IIRC, it uses the name first, and if there is no match, then it uses the IP address. It seems strange to me to have the same name for multiple server instances on the same machine. How about the ability to give each server instance a different name?
Sure, the enhancment request of bug 3592 will fix it, given the current firmware behavior. I just think that it's unnecessary and that the firmware already has all the info needed to recognize the servers as unique. It's mostly just an issue in the SB setup screen, so that you could pick from the other servers. Right now, only one of them is displayed. If bug 3592 is what you decide should be the best way to handle the issue, then I'll close the bug again, but would really like to see 3592 moved up and targeted for 7.x.
*** This bug has been marked as a duplicate of 3592 ***