Bugzilla – Bug 15396
SBS Can't fetch SqueezePlay clients back from Mysqueezebox.com
Last modified: 2011-07-25 02:48:36 UTC
Given a SqueezePlay $client: $client->execute(['connect', Slim::Networking::SqueezeNetwork->get_server('sn')); ..works to push the Controller/Touch/etc. onto Mysqueezebox.com. This is confirmed by going to the client's 'My Music' menu which will report that a library switch is necessary to return to the local server. However: my @aSNPlayers = Slim::Networking::SqueezeNetwork::Players->get_players(); ..does not list the SqueezePlay client as being 'on' Mysqueezebox.com, and: $request = Slim::Control::Request::executeRequest(undef, [ 'disconnect', $macaddr, $snserver ]); ..fails to fetch reconnect the SqueezePlay client to the local server. SqueezePlay clients should still be controllable by Squeezebox Server for an entire localsbs -> mysqueezebox.com -> localsbs round trip. Also, while IP3K players get listed on the SBS web UI when connected to mysqueezebox.com, SqueezePlay players do not. Again, this represents a loss of control by the user over the SqueezePlay client. The user ought to be able to 'bring back' a SqueezePlay client and resume local playback using the WebUI.
Gordon - if you say "Squeezeplay player", are you talking about hardware devices or the desktop player? My Radio shows up just fine in my local SBS. Just make sure you're looking at the correct instance (which currently is a bit confusing): while 7.5 is pointing at test.mysb.com, only Touch will connect there. Controller and Radio will still connect to www.mysb.com. Yes, that's confusing and sometimes a big pita to test stuff with.
OK, testing with SBS 7.5 embedded svn 29724 on Fedora 12: Michael: are the following generic problems with SBS 7.5 and www.test.mysqueezebox.com? I'm finding different behaviour between a boom, a sbc, a sbr and a sbtouch in terms of their interactions between SBS and www.test.mysqueezebox.com. I have to say, this is more than a PITA, it seems like a real mess. Basically, only the boom and the SB3 behave as expected. The SBR and the SBC and SBTouch really seem 'broken' in terms of their behaviour. SBR problem: With a Squeezebox Reciever, once it's been "pushed" to www.test.mysqueezebox.com, there isn't any way to pull it back to the local SBS. The "disconnect" button on the test.mysqueezebox.com web site doesn't work. The SBS webUI player select doesn't work. And once the SBR has connected to www.test.mysqueezebox.com, it "disappears" from the list of available players that the SBC sees. The only way to free the SBR from the clutches of www.test.mysqueezebox.com is to do a factory reset and set it up again. SBTouch problem: I can push the sbtouch to www.test.mysqueezebox.com via CLI, but CLI 'disconnect' doesn't work. SBTouch says on www.test.mysqueezebox.com and the SBS webUI can't pull it back either. The only way to reconnect the Touch to the local SBS is via the Touch's 'switch library' screen UI. But even after the Touch has switched back via 'switch library' and the SBS webUI shows the touch as connected, Slim::Networking::SqueezeNetwork::Players->get_players() STILL lists the touch as being connected to www.test.mysqueezebox.com!!! SBC problem: Pushing a SBC running 7.5.0 r8279 to www.test.mysqueezebox.com via CLI succeeds, as long as the SBC 'player' is NOT controlled by the SBC. The 'players' web page at www.test.mysqueezebox.com lists the SBC as 'connected.' However, the local SBS webUI no longer lists the SBC as an available player and Slim::Networking::SqueezeNetwork::Players->get_players(), while listing other players connected to www.test.mysqueezebox.com, does not list the SBC. -------------------------------------- What's going on here? These inconsistencies are making it impossible to do any effective programming involving the CLI, SBS 7.5, SqueezePlay-based hardware and www.test.mysqueezebox.com. Is this a case of the CLI just being broken in 7.5 at this point? Are JSON interfaces working where the CLI is broken?
..and yes, I'm talking exclusively here about hardware players: SBTouch and SBC. I wasn't on the radio beta so I don't have one to test with.
> www.test.mysqueezebox.com? I'm finding different behaviour between a > boom, a sbc, a sbr and a sbtouch That's to be expected: SBC will _not_ connect to test.mysb.com, the others will. But as long as you're going through SBS, this shouldn't matter. > The only way to free the SBR from the clutches of > www.test.mysqueezebox.com is to do a factory reset and set it up again. I'll have to test this. Sounds really bad. > Slim::Networking::SqueezeNetwork::Players->get_players() > STILL lists the touch as being connected to www.test.mysqueezebox.com!!! This sounds like a smallish bug: the list is only updated from information from SN, but not local knowledge of connected players. > SBC problem: Classic or Controller? > What's going on here? These inconsistencies are making it impossible to > do any > effective programming involving the CLI, SBS 7.5, SqueezePlay-based > hardware and www.test.mysqueezebox.com. As I said that's currently a problem, as the mysb.com instance to be used is on the player for SP devices. All but Touch currently point to the production system. You can't easily connect them to test. I know it's a pita, because I have to work around this myself.
Felix - what's the latest news about udap switching players from/to SN?
Michael - UDAP is not used / needed for switching back and forth a still _connected_ player between mysb.com and SbS or more generically switching between two running / available servers. UDAP only is needed in case a player gets _disconnected_ from a server (i.e. PC has been turned off). The player then falls back into 'connecting' stage and accepts another server via UDAP. Also UDAP uses UDP packets which means it is only available between devices which are in the same subnet. Setting a server via UDAP is implemented in ip3k and sp based players. Bug 12207 I am wondering whether the current confusion is because we are using test and regular mysb.com at the moment for different players?
For me, SBC == Squeezebox Controller. The 'classic' has always been SB3 in my personal nomenclature. Felix: the test != mysb.com situation certainly contributes to my confusion. But I think I've raised some valid questions: 1). Why does the SBR get 'marooned' on test.mysb.com and is invisible to Slim::Networking::SqueezeNetwork::Players->get_players() when 'sn' points to test.mysb.com? 2). Why can't the SBS 7.5 embedded webUI pull a SBTouch from test.mysb.com to the local music source? ..etc.
QA to make sure after the test.mysb launch to make sure there is no serious problem here, and re-evaluate for target and priority.
This is still a problem, by the way. I can't switch my SBTouch back from mysqueezebox.com to the local server with either a CLI command or by using the webUI.
Was set to resolved by mistake.
== Auto-comment from SVN commit #9893 to the network repo by agrundman == == http://svn.slimdevices.com/network?view=revision&revision=9893 == Fixed bug 15396, use connect CLI command for disconnecting SP clients
Could this bug be reopened please? This is still not working. Using: SBS 7.6 svn 31816 SBTouch 7.6.0 r9297 A CLI command to the local SBS: 00:04:20:aa:bb:cc connect www.mysqueezebox.com ..succeeds and the Touch is connected to mysb.com. Attempting to use the local SBS's webUI to reconnect the Touch to the local SBS fails. The CLI command to the local SBS: ..also fails to return the Touch to local SBS control.
Still not working as of 20110124.
Ran into the same problem with a brand new Touch last evening. It's still a bug.
Tread here: http://forums.slimdevices.com/showthread.php?t=85908
*** Bug 17029 has been marked as a duplicate of this bug. ***
Created attachment 7307 [details] Gordon's patch from bug 17029
== Auto-comment from SVN commit #10651 to the network repo by mherger == == http://svn.slimdevices.com/network?view=revision&revision=10651 == Bug: 15396 Description: leave the handling of SP based players to the disconnect CLI command
Gordon - I decided not to apply your patch, but to fix this on the SN side (as this was broken). But your patch was helpful to understand what was wrong anyway, thanks! I think this is now fixed on test.mysqueezebox.com. May I ask you to confirm the fix on the test system before we roll it out to production?
I may be able to test this tomorrow or perhaps sometime next week when I'm in Montreal. Can you remind me how to make the local SBS see test.mysb.com? It's a setting in server.prefs, isn't it?
I've set up a quick wiki page describing the process, as it's not obvious with SqueezePlay based players: http://wiki.slimdevices.com/index.php/How_to_connect_your_Squeezebox_to_test.mysqueezebox.com
Michael: I'm sorry, but it's going to be a month or more before I can test this. I'm in remote upstate NY without a SBS server with Internet access. (I'm posting this using my iPad.). I'm going to have to order a new SBTouch and when I'm back home in July, I should be able to verify your fix.
Hey Bradley, could you test this out and see if things are better?
Let's please roll this change out to production systems: bluegaspode has reported the same issue he encountered while working on SqueezePad. He confirmed that it did work on test.mysb.com again.
== Auto-comment from SVN commit #10755 to the network repo by mherger == == http://svn.slimdevices.com/network?view=revision&revision=10755 == Bug: 15396 Description: rolling fix out to production systems