The way it currently works, you need to disable autodiscovery if you want to select a single server, but you have mutiple servers.  This is because there is no filtering of which servers respond, the SettupSlimServers changes the list of ip address a discover poll is sent to, but jive uses all responses.

The original version automatically disabled autodiscovery if a manual entry is added, but Richard preferred it the way it is currently.

Is there something fundamental about how it works now or can we fix it so that autodiscovery and manual entry can coexist? 
Squeezebox allows for both.   The user shouldn't have to know about the internal state.

Well I think the requirements are slightly different from Squeezebox as you potentially want to allow multiple slimservers at one time.  However I think the way I had it of disabling autodiscovery when you add a manual entry is the simplest for the user - but Richard didn't like that...

I'm confused.  Why not allow for the list to contain auto-discovered servers and add a manually entered server?

This should also be the mechanism to move the selected player to a different server (and possibly discover new players on a manually entered server.)

It depends - if you want to use this to manually select _one_ server when you have a set of servers which respond to autodiscovery, you need to disable it.  

So I see two reasons for this applet:
1) to allow you to connect to servers which are not on the same subnet
2) to allow you to force use of only specific servers, i.e. not to use all servers which respond to autodiscovery.

In the second case you need to either stop sending probe packets or filter the responses, the impact on the user is the same.  What we are arguing about is how the user sees this, should disabling autodiscovery be automatic when you add a specific server, or should it be a separate configuration.

Ah, ok.  So here's how we were seeing it differently.

I wasn't thinking about the second item you listed at all.  We currently have a problem where old servers respond to the discovery packets and it causes performance problems, at least in our office network, where there are probably a dozen servers.  That's not a problem that folks will see in the field and is easy to fix in any case.

The first item is good, we need a way to manually get the address of a server that's not immediately discoverable.  That should get added to the list of servers that we query for players to display when we hit the Choose Player menu.  So the Choose Player list will contain all of the local servers as well as the remote server, if entered.

The other function of the Music Source menu is to switch a chosen player to another server, which includes SlimServer.  We talked about this capability in person this week and seems like a natural fit for this menu.

What am I missing?

Well you shouldn't have the problem of legacy servers now as jive uses a new discovery packet format.

However, I think it is a mistake to discount the posibility that there may be local servers present which you don't want to discover.  This will be a corner case, but I can imagine some cases where people share home networks or have a single network in shop and don't want people attaching to all servers at once.

So I've moved and renamed this in r494. But Dean I don't think this is what you really want.

Also this worries me "The other function of the Music Source menu is to switch a chosen player to another server, which includes SlimServer.  We talked about this capability in person this week and seems like a natural fit for this menu.". We were discussing switching Squeezebox's to different servers from Jive, that is completely different from telling Jive that another Music Source exists. I'm not sure one menu can perform both functions?

For most users, they'll just want to switch the current player to a given server or SqueezeNetwork.  That's Music Sources.  Triode also suggested that we also need a way to enter the IP of a specific server so that Jive is aware of it.  

I don't think that disabling auto-discovery is an important end-user feature.  Only, maybe, useful on our local office network or maybe on a public WLAN, but the danger is low and the user is in control.

Richard notes this is complicated.

*** Bug 6151 has been marked as a duplicate of this bug. ***

Is there anything left to do on this bug?

As far as I can tell, most of the desired behavior originally posted in this bug is how it works now...

I'll steal this bug.

After some thought the Choose Player screen needs to discover players connected to squeezecenter and in setup mode (both adhoc and udap). If they are in setup mode then the network configuration and/or squeezecenter configuration will be completed from this screen. This will allow you to switch players to a different server, or squeezenetwork.

changing title to be more specific to richard's last comment.  Other work moved to new bug 6303

*** Bug 6564 has been marked as a duplicate of this bug. ***

Various changes up to r1534.

Choose Players now will find Squeezebox Receivers in udap or ad-hoc setup mode, and will configure them as appropriate.

QA:  Please verify and test this new behavior.

I used the feature to add a second Receiver to my server.  It worked to set it up fine.  But...

After successful setup if you go back to "Choose Player" it still lists the new Receiver as "Squeezebox 16025B" when the server named the player "Squeezebox Two".  The first Receiver is correctly listed as "Dan_Ray".

I renamed the player to "PQP3".  If I go to "Choose Player" I see the new Receiver listed as "PQP3" for just an instant and then it's listed again as "Squeezebox 16025B".

Fixed player name as seen in Choose Player in r1683.

This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html