Bugzilla – Bug 13428
When disconnected player is renamed, it will revert after reconnecting
Last modified: 2009-10-05 16:42:57 UTC
Created attachment 5620 [details] MySB.com being confused with two player names for one ...or not even fully revert, but confuse the web UI: I'm currently seeing both old and new names being used.
At the same time the player was hardly usable, as it was slowed down to a crawl. Which reminded me of some bug we had in 7.0, where there was some kind of a race condition when renaming players. Once I've restarted the player, everything returned to a good state: SN returned unique values for the player name, and the player was usable again. QA: could you please try to reproduce this: - go to mysb.com - rename a player (boom or classic) while it's not connected to SN - connect the player - go the My Squeezeboxes -> do you see the correct name in all places? -> is the player UI being slowed down?
Matt - player names are stored on the device. Thus as soon as the player is connected to SN or SC it will update that server's database to use the name stored on the player. Should we therefore disable changing player names if a player is disconnected?
== Auto-comment from SVN commit #7020 to the network repo by michael == == https://svn.slimdevices.com/network?view=revision&revision=7020 == Bug: 13428 Description: Matt - I've disabled the name input field when player is disconnected. There's a hint "You need to connect your player to mysqueezebox.com if you want to rename it." telling the user what to do. Please translate that string into correct language :-).
Assigning to Matt for text copy review. Feel free to close if you're happy with it.
== Auto-comment from SVN commit #7021 to the network repo by michael == == https://svn.slimdevices.com/network?view=revision&revision=7021 == Bug: 13428 Description: changing text to "In order to rename your player please connect it to mysqueezebox.com."
(In reply to comment #3) > == Auto-comment from SVN commit #7020 to the network repo by michael == > == https://svn.slimdevices.com/network?view=revision&revision=7020 == > > Bug: 13428 > Description: Matt - I've disabled the name input field when player is > disconnected. There's a hint "You need to connect your player to > mysqueezebox.com if you want to rename it." telling the user what to do. Please > translate that string into correct language :-). "To rename this Squeezebox, please connect it to mysqueezebox.com."
== Auto-comment from SVN commit #7023 to the network repo by michael == == https://svn.slimdevices.com/network?view=revision&revision=7023 == Bug: 13428 Description: updated text copy
I hadn't noticed this bug report before, but I've seen the symptoms quite often. I barely use SN, but players are constantly being renamed or the name I'd given them from the local server is lost and reverted to the default name. You need to have two way syncing to handle this properly, don't you? Which would involve timestamping any individual setting and either pushing the new one to the player or vice-versa, depending on which is most recent. The solution proposed isn't exactly what I'd expect of the seamless SN integration that I've seen talked up in the forums.
Andy proposes that we include a timestamp in the sync data so we can tell what the latest name should be. QA to test 3 cases: * if you are connected to SN, it should change straight away * SC (w pref sync enabled): may take 5 minutes, but should work * Not connected to any server: change name, see if the server picks it up Based on that, we can come up with the message
QA tested 3 cases: * if you are connected to SN, it should change straight away = Correct, working * SC (w pref sync enabled): may take 5 minutes, but should work = Correct, working * Not connected to any server: change name, see if the server picks it up = Device auto-connects to SN (MySB.com) & prompts to change name on device. SN picks up change immediately, SBS picks up change @ next player connect
I found 1 case where this is still an issue --------------------------------------------- Disable SC > SN sync. Attach a player to SBS, on Player, rename the device Look at SBS and see the name change Enable SC > SN sync Player name changes to what SN has stored Expected behavior is that SN will update with player name NOT, Player update with SN name
== Auto-comment from SVN commit #7368 to the network repo by michael == == https://svn.slimdevices.com/network?view=revision&revision=7368 == Bug: 13428 Description: disable playername sync between SC and SN. Always use the value stored on the player. QA - could you please verify the name overwriting doesn't happen any more, even when synching is temporarily disabled and re-enabled etc.?
We've now disabled name synching. Please test again and re-open if needed.
This is still screwed up. The name reverts to whatever is on SN, no matter what you do. If I rename the SB Radio while connected to the local SbS then it reverts to the SN name within a few minutes.
QA confirmed, using the steps in comment 11, I am able to get SN to overwrite player name.
*** Bug 13996 has been marked as a duplicate of this bug. ***
Andy - this patch would prevent the player name sync: Index: server/Slim/Networking/SqueezeNetwork/PrefSync.pm =================================================================== --- server/Slim/Networking/SqueezeNetwork/PrefSync.pm (revision 28632) +++ server/Slim/Networking/SqueezeNetwork/PrefSync.pm (working copy) @@ -230,12 +230,6 @@ $cprefs->remove('snSyncErrors'); - # Sync name if different - if ( $content->{name} && ( $content->{name} ne $client->name ) ) { - $client->name( $content->{name} ); - main::DEBUGLOG && $log->debug( 'Updated player name to ' . $content->{name} . ' from SN' ); - } - while ( my ($pref, $data) = each %{ $content->{prefs} } ) { if ( $pref =~ /\./ ) {
Ah right, yes.
== Auto-comment from SVN commit #28633 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=28633 == Fixed Bug: 13428 Description: remove player name synching code from the SC side too
This bug has been fixed in the latest release of MySqueezebox.com (formally known as SqueezeNetwork)! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.