Bugzilla – Bug 10002
Connecting a player from one password protected SC to another makes Controller lose connectivity
Last modified: 2011-11-06 23:23:25 UTC
Take two password protected SC. Player is connected to A, Controller is asking for login/pw of SC A. Use Controller to connect player to SC B -> while the player connects, Controller won't ask for the new login/pw. Tries to connect, eventually giving up with a network failure message.
Two more comments: 1) The PLAYER will successfully connect to server B. If you ever planned to connect your player to your neighbor's server and not get it back - that's the way to do it. 2) The error message says "Sequeezebox could not connect to the wireless network", which is confusing in two ways: it's not the wireless network the controller cannot connect to, but the server and it is also not the PLAYER that cannot connect, but the controller.
Is the logon name / password the same or different between the 2 servers?
Different. Can't expect different servers to have the same credentials, right?
Also, attempting to setup a factory reset duet to a SC with password fails. I get the "problem connecting; go back; try again" error messages
Any relation to bug 5887
Connecting IP3k players to a protected SC I do not get prompted with logon credentials. The players just log right in, is this correct?
SC 7.2.1 works fine. Richard, would this be yours to look at?
We are now planning to make a 7.3.3 release. Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future. Thanks!
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out. If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it. Thanks.
Reset priority before triage.
Moving to a P2, as the set of users impacted is likely quite small (they need to have multiple SCs _and_ have them password-protected). Once we see how full we are, perhaps we can pull this one back in.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Unassigned bugs cannot have a priority.