Michael & Alan were talking about this issue earlier in the week.  The 3 UIs should be consistent...

We did align SBC & web interface. But if SBC is _not_ showing synchronized players, then this is imho the problem here. In the web interface I tried to check the players which already are synched.

The problem is that all UIs (player, Web, SBC) operate from the perspective of a particular player (THIS). When it comes to sync, the implementation options are:

(a) Make THIS play what player X (or sync-group {X, Y}) is already playing. That is, add THIS to X's sync-goup.
(b) Make X play what THIS is playing. That is, add X to THIS's sync-group.

Is synchronization a pull or push operation?

The player-UI does (a). The SBC and Web-UIs do (b).

In both modes there are cases where adding a player to one sync-group first removes it from another sync-group, and the UIs do not provide a means to tell you this.

For mode (b) UIs, the display shows which other players THIS is already synced with. Of the players not currently synced with THIS, it does not indicate which are in other sync-groups. Syncing with such a player will remove it from its existing sync-group and add it to THIS's sync-group. This might be what you want, or it might not; you might want: (1) to add all the players in a different sync-group to THIS's group, (2) you might want to add THIS to the other sync-group, (3) you might want to do what happens.

Coming up with a UI that users can comprehend, that allows users to do all the different combinations that they might wish, including providing suitable feedback is hard.

Your (Peter's) suggestion is to make SBC work like the player-UI: option (a). It is clear that neither scheme is entirely adequate but I think that it is too late to consider changing things for SC 7.0.

> Your (Peter's) suggestion is to make SBC work like the player-UI: option (a).
> It is clear that neither scheme is entirely adequate but I think that it is too
> late to consider changing things for SC 7.0.

Just to confuse things a bit more: this option is still available from the Settings/Player/Audio page.

re: #4: that's the only spot for this in the web UI, right?

Alan: good points re: mode a) vs. b). I prefer a) not simply because I'm accustomed to it but also
 - It fits my actual behavior. I often start listening to a playlist in one room, find myself wander into a nearby or adjacent room for something, and want the music to "expand" into both spaces (not "move" as the GrabPlaylist plugin provides, but expand so it's playing in both spaces). So I ask the player in the "new" room to sync with what I already had playing in the "old" room.
 - It seems better for households like mine that have multiple players and multiple users. If I'm moving from the basement to the bedroom and want the music to follow me, the current mode a) VFD/IR/web-settings model encourages me to wait until I get there, rather than impose my music only to find my wife was perfectly happy with whatever she had been listening to. :-)

> re: #4: that's the only spot for this in the web UI, right?

No, you can open a sync dialog from the players drop down list in the main window. This dialog uses a Jive style checkbox list with players available.

Maybe for now it'd be good to start using different phrases for 
- the IR/web settings model that makes the player a slave to another single player or established sync group and 
- the Jive/web checkbox model that creates new sync groups with the current player as the master. 

I'd suggest using the English phrase "Join up with" for the older mode, and "Take control of" for this new mode that's appeared in SC7 and that I don't like as much. Yeah, it's more translation, but that's where those Logitech i18n folks ocme in, right?

At least with more explicit labels, this new "backwards" behavior would be less confusing to those of us wh've been using Squeezeboxes for years. :-)

Going forward, I think the UIs could offer a branched model:

Synchronize
....Join up with another player
........Join up with B
........Join up with C and D
....Take control of another player
........Take control of B [ ]
........Take control of C (synced with D) [ ]
........Take control of D (synced with C) [ ]

Given a bit of time and brain effort the average user can understand the options presented the branched menu that Peter offered.  Its true it covers clearly all possibilities.  BUT it does force the average user to do a fair bit of THINKING - which I think is generally not a good thing.  Most users are very happy and familiar with the "Join up with" behavior of the boxes.  From the WebUI (and I guess from the SBC - on order!) you can EASILY take the view of any player.  So why complicate the sync with options to push (takeover) or pull (join up with)?  Why not just ALWAYS pull (join up with) - so the user doesn't have to think - and if you want to push then just switch to that play and pull.  Here is how Peters menu options map with an always pull (join up with) sync:

Join up with another player
...Join up with B                         ----> Sync with B
...Join up with C and D                   ----> Sync with C and D
Take control of another player
...Take control of B [ ]                  ----> Switch UI from A to B and Sync B with A.
...Take control of C (synced with D) [ ]  ----> Switch UI from A to C. Unsync C. Sync C with A.
...Take control of D (synced with C) [ ]  ----> Switch UI from A to D. Unsync D. sync D with A.

You might argue that the steps are much more complicated and require more thinking than the branched menu but I think they look more complicated here than they are in the mind of the user.  For example in the "take control of B case" A user who is used to thinking "join up with" will just automaically start his UI on B and just sync with A.  The "Take control of" options are only there because the user has the UI on the WRONG machine.  If there is a simple and consistent "Join up with" philosophy then users will just pull from the right machine without thinking.

Maybe I have overlooked something...

Michael, is the sync ui a 7.1 fix?

Alan, what are your plans for sync in upcoming releases? I don't want to spend time on this if there are some fundamental changes in the pipeline.

I will not get to this in time for SC 7.1.

punting to 7.3

New proposal for a unified interface for Controller/Jive and Player/VFD:

Two levels of menus:

Level 1, like INPUT.List : list all current sync groups and solo players, alphabetized. When the user enters this menu, the current player (player that the Controller is controlling, or player receiving the IR input) or the sync group containing the current player should be selected/highlighted.

Level 2, like INPUT.Choice: list all players, alphabetized, with checkboxes. Any player that's in the sync group that was selected when the user entered level 2 would have its checkbox checked. If the level 1 choice was a single player, only that player's checkbox would be checked. When the user enters level 2, the current player would be selected.

In level 2, unchecking a box would make that player leave all sync groups (go "solo"). Checking a checkbox would force that player to leave any group it was in and then join the sync group described by the checkboxes in the current level 2 choice list.

Sample menu hierarchy with 
- players Player A, Player B, Player C, Player D 
- Player B and Player C are synced
- the user is interacting with/controlling Player D:

Synchronize

  Player A
    Player A [x]
    Player B [ ]
    Player C [ ]
    Player D [ ] <- initially highlighted if Player A chosen

  Player B & Player C
    Player A [ ]
    Player B [x]
    Player C [x]
    Player D [ ] <- initially highlighted if Player B & Player C chosen

  Player D <- initially highlighted if Synchronize chosen
    Player A [ ]
    Player B [ ]
    Player C [ ]
    Player D [x] <- initially highlighted if Player D chosen

(In the web UI, I imagine the level 1 groups would be implemented as collapsible panels/spans.)

For Jive/Controller, this means one more wheel tap after Synchronize would give users the "push" menu that was there in SC 7.0.

For IR remote users, they'd have at least one more click, too, but the normal "pull" use cases would be similar to pre-7.0: scroll til you see the player or sync group you want to join, tap right, but then tap right one more time.

Both Controller and IR UIs would have easy access to "push" and "pull". And there'd be no need to decide on "push"/"pull" lingo or otherwise move away from the "sync" description.

Both interfaces would have an easy way to see what the current sync groups were (scroll through level 1), much as the old IR/VFD/player UI had before 7.0.

This ought to be smart & friendly enough to handle use cases like:

1) user enters "Player B & Player CB" on level 2, checks A, checks D, unchecks B, unchecks C, and ends up with A & D playing the playlist that B & C were handling (and B & C becoming silent solo players). Upon left arrowing back to level 1, the user would see entries "Player A & Player D", "Player B", and "Player C".

2) user enters "Player A" on level 2, unchecks A, checks D, checks B, and ends up with B & D playing what D had been playing, and A remains solo and silent. Upon left arrowing back to level 1, the user would see entries "Player A", "Player B & Player D", and "Player C".

3) user enters "Player A" on level 2, unchecks A. No change is effected. User arrow left to level 1 and sees the same options as before

Matt: you are looking at the UI for sync.  Are we done here?

Liberace improvements will compartmentalize sync features into an "application" that multi-Squeezebox owners can install/reveal.  This will make it a lot easier for us to develop one or more versions of an improved UI for syncing...

(In reply to comment #8)
> Why not just ALWAYS pull (join up with) - so the user doesn't
> have to think - and if you want to push then just switch to that play and
> pull.

Prior to version 7.3 (I believe) my Controller had the "push" option. I really liked it and it was easy to sync multiple players. After version 7.3 I have the "pull" option which means it is a lot more difficult to sync players.

Consider these examples with three players A, B and C:
I am currently controlling A.

Scenario x)
Synchronize B and C with A, so B and C play what I'am currently listening to using A

Scenario y)
Break synchronization again so I can continue listening to A -- i.e. remove B and C from the synchronization group.

Before SC 7.3:
Scenario x)
1) Go to Settings > Synchronization
2) Select the checkboxes next to B and C.
Done.

Scenario y)
1) Go to Settings > Synchronization
2) De-select the checkboxes next to B and C.
Done.

After SC 7.3:
Scenario x)
1) Switch to player B
2) Go to Settings > Synchronization
3) Synchronize with player A
4) Switch to player C
5) Go to Settings > Synchronization
6) Synchronize with player A (or B if you like)
Done.

Scenario y)
(We are now controlling player C since we are where we left scenario A. If we are controlling any other player, we need a step more.)
1) Go to Settings > Synchronization
2) Remove this player (C) from the synchronization group.
3) Switch to player B.
4) Go to Settings > Synchronization
5) Remove this player (B) from the synchronization group.
6) Switch to player A to be able to control volume, track, etc.


IMHO things are a lot more difficult after the release of SC version 7.3.

If I should choose between "push" (i.e. sync other player to me) or "pull" (i.e. sync my player with another player) -- and could not have both --, I would definitely choose to have "push" like before version 7.3.

As logn ad you have 2 players it doesn't really matter, but going to 3 or more makes the current "pull" UI in the Controller very annoying.

(In reply to comment #13)
> New proposal for a unified interface for Controller/Jive and Player/VFD:
> 
> Two levels of menus:

Very interesting thoughts!

I'm looking forward to seeing what will happen in 7.4.

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

Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code.  Feel free to move it back if it's specific to the single original product.

Reset priority before triage.

Sync should be reviewed in 8.1

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

Bug 11011 and bug 10219 are also relevant to and Sync UI redesign

Moving Matt Weldon bugs

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

Unassigned bugs cannot have a priority.