> I've had 2 recent cases where my usual CLI command for reconnecting to > SB upon server wake-up creates a situation where the player is declared > connected both on mySB and on SC.
Please note that mysb.com can take a few minutes until player states are synced across all mysb.com server instances. If you happen to send the disconnect to one instance but check on another, you might see a delay. Could this be the reason for the behaviour you're seeing? > As it is not really on mySB, hitting > disconnect in mySB's web UI doesn't work. > It only worked when I reconnected again to mySB (from SC) and then hit > the disconnect button. Didn't you check through the same connection as you sent the disconnect then? > Hence I decided to replace my CLI "disconnect" command with a query to > mySB.com. ?!? CLI disconnect command on what? SBS? mysb.com? If you look at SBS' implementation you'll see that all this command does is send a query to mysb.com to do this. > Right now, the initial CLI "connect" command is still in use, and SC > sends the player to mySB.com before going to sleep. Upon server wake, my > script uses the Json "connect" command above, and the player is properly > switched back and reconnected to SC. Please note that the only difference between CLI and JSON is the transport: the first version is connecting directly to a socket, JSON is using http. But the command execution is the same. > Time will tell if this is a robust solution. Let's sum it up (in case this actually was a misbehaviour on mysb.com): using the "disconnect" command on SBS to get a player back from mysb.com to SBS, the state on mysb.com wasn't updated immediately. But if you use JSON (I still don't know where you're sending this command... on mysb.com?) to do a "connect" back to SBS, all is fine? -- Michael _______________________________________________ squeezenetwork mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezenetwork
