PDA

View Full Version : Synchronization for dummies



MeSue
2009-01-30, 12:54
I have tried out syncing 2 players in the past but never used it for any length of time. Yesterday I was trying to sync players and could not figure it out. Here are two scenarios I would like to accomplish and would appreciate some guidance on how to achieve what I want--either with the built-in sync options or the Other Players plug-in. I'm running Squeezecenter 7.4.

Scenario 1:
Player A is on and playing.
I want to bring a Player B into sync with Player A but without losing the playlist on Player A. So player A would just continue in what it is playing, and the same sound would begin coming from Player B.

How do I know which player is the one that keeps its playlist when I initiate the sync?


Scenario 2:
I would like to have 3 players using the same playlist but not necessarily all playing at the same time. I just want to be able to go from one room to another and have the same playlist picking up where the other one left off, but only turning on the player for the room I am in. In other words, I want to turn off the player in the room I am leaving, go to a new room and turn on that player to pick up the same place in the playlist.

Is this one even possible? Yesterday when I was messing around I couldn't seem to get more than two players in a sync group. Adding a third player always removed the second one.

sc53
2009-01-30, 13:17
My experiences with the above scenarios: you have to remember which player you have the playlist on. If Player A is the one with the playlist, just hit the "sync" button in the dropdown box at the top of the SC webpage window and select "Player B." Then B will start playing A's playlist. As for your second scenario, my setup does not work in the way you are envisioning. In fact, say I've sync'ed Player B with A as described above. If I turn off A because I leave that room, B will continue playing A's playlist anyway, it won't stop playing. And B will resume the playlist where IT left off, not where A left off when I turned off A.

Mnyb
2009-01-30, 13:30
If you are using the controller you have to choose player "B" and sync it to "A" if "A" is playing the playslist.

Scenario 2 is fun : ) get the "other player" plugin, the new version . Then you can actually send playlists to another player and grab playlists from another player to the one you are using now .

Edit:http://forums.slimdevices.com/showthread.php?t=57617

MeSue
2009-01-30, 15:01
Okay, I have the Other Players plugin and have used the grab/send playlist... works great! I thought that if they were synced that this could happen automatically, but if I have to grab the playlist every time I move from one room to another that is fine.

Back to scenario #1, based on the 2 answers I have received, it sounds like the behavior is different depending on whether you are using the webUI or the controllerUI. That would explain my confusion after messing with it yesterday.

So from the WebUI, I want to have the player A selected, then choose sync and pick player B and B will begin playing A's playlist.

From the Controller it is opposite; if I want player A's playlist on B, I have to go to B and sync it to A and then B will start to play A's playlist.

Have I got that right? How does it work on the classic playerUI?

I'd ask about bringing a player C into the mix, but I don't think my brain could take it right now!

pippin
2009-01-30, 15:14
Get yourself an iPod touch and use iPeng :-)
Makes life a lot easier with syncing.

peterw
2009-01-30, 17:58
Get yourself an iPod touch and use iPeng :-)
Makes life a lot easier with syncing.

Sheesh, pippin, would ya give the sales pitch a break?!?

MeSue -- in SqueezeCenter 7.0 through 7.2.x, the main page of the web UI and the Controller UI had a different interpretation of "sync" than did the player UI (and web settings page). The main web page and Controller UIs were modified to behave like the older player and web settings UIs in SqueezeCenter 7.3. Some future release should feature yet another change to make all this more clear & easier to use -- see http://bugs.slimdevices.com/show_bug.cgi?id=6806

-Peter

pippin
2009-01-30, 18:10
Sheesh, pippin, would ya give the sales pitch a break?!?


No, because at least for the Web Interface I won't understand why it can't be done in a similarly comfortable way. I would even offer some code (from the iPeng skin, which already did the same).

MeSue
2009-01-30, 20:09
Get yourself an iPod touch and use iPeng :-)


I'm not an iFan, and that's really overkill for something I'm only going to use occasionally.



Some future release should feature yet another change to make all this more clear & easier to use -- see http://bugs.slimdevices.com/show_bug.cgi?id=6806


Good to know it is being discussed/thought about. Hope it doesn't take too long to be implemented.

I think the grab/send playlist scenario using Other Players will cover the majority of my needs since I don't have many parties, and am rarely in two places at the same time. ;-)

peterw
2009-01-30, 20:24
at least for the Web Interface I won't understand why it can't be done in a similarly comfortable way. I would even offer some code (from the iPeng skin, which already did the same).

I'd love to see a patch that improved the sync UI. Please do post a patch! If you upload it to bugzilla, please at least post a note in the forums so we don't miss it.

awy
2009-02-02, 08:30
Probably the best way to think about thisat the moment (don't flame me about how it should work - I'm just trying to explain a way of thinking about how it does work) is as follows.


There exist sync-groups.
A playlist belongs to a sync-group.
Every player belongs to exactly one sync-group.
Sync-groups are not named and can be manipulated only via (the UI of) a player which is a member of the group.
A player can join or leave a sync-group. If it joins, and was previously the only player in its old sync-group then that old sync-group ceases to exist. If it leaves, then it forms a new sync-group containing only itself; it normally takes a copy of the playlist with it.
Thus, one must manipulate (control) the player that is not currently in a particular sync-group in order to get it to join (or leave) that sync-group. On cannot use a UI that is controlling a sync-group (via one of its existing member players), to grab another player and add it to the current sync-group.
Players in a sync group which are off are still part of the sync-group. When turned on they will pick up playing whatever the other players in the sync group were playing (if anything), joining in the middle of the current track if possible.


This is not exactly how this all actually work but I hope it provides a useful mental model.

MeSue
2009-02-02, 09:05
Thanks! That clears up a lot.

I'm still not sure which playlist is retained when you start out with nothing synced and initially sync 2 players that each have a different playlist, but I can experiment more to figure that out now that I have better understanding of it all.

oreillymj
2009-02-02, 09:07
Alan,

I know you've done great work in getting sync to work reliably.

However what's still needed is an Apple style UI which makes it easy for the user to understand what they are about to do. The underlying complexity should be hidden and have the UI and players work differently makes it hard to know what will happen.

I think it comes down to what player the user is actively controlling and what get's displayed on the UI. Also, what is the users intent?

If I'm using the Jive remote to control my Duet and I ask to synch with an SB3, the SB3 should get the Duets playlist and begin playing. If the underlying implementation means that you need to tell the SB3's synch-group to join the Duets, then so be it.
What I don't expect to happen is for the Duets playlist to be lost when it synchs with SB3. The intent is based on the fact that I'm controlling the Duet.

The same would apply to an SB3 if I was standing in front of it using an IR remote. If I select Synch with Boom using the remote, then I expect the Boom to begin playing the SB3's playlist.

markbieg
2009-02-02, 09:54
Hello,

Just my two cents since I have 3 players (Duet, SB3 and Boom) and have been confused and mixed up a couple of times trying to sync players. It gets really confusing when using the SBC to control all of the devices, bouncing back and forth selecting which device to control and then trying to sync from whatever is currently selected. I think part of the problem is with the concept of "sync with...". It is not specific enough.

Why not use new terms like "join" and "share"? And, give both choices to the user no matter what box they are currently controlling. For example, if I have the SBC currently on the Duet receiver and want to sync with the Boom, I would get the choices to "1. Join Boom" or "2. Share with Boom". The first choice to "Join" would have whatever is playing on the Boom also play on the Duet. The choice to "Share" would have whatever is playing on the Duet also play on the Boom.

Would that make things more clear?

peterw
2009-02-02, 14:55
If I'm using the Jive remote to control my Duet and I ask to synch with an SB3, the SB3 should get the Duets playlist and begin playing. If the underlying implementation means that you need to tell the SB3's synch-group to join the Duets, then so be it.
What I don't expect to happen is for the Duets playlist to be lost when it synchs with SB3. The intent is based on the fact that I'm controlling the Duet.

The same would apply to an SB3 if I was standing in front of it using an IR remote. If I select Synch with Boom using the remote, then I expect the Boom to begin playing the SB3's playlist.

In your second case, I expect the opposite. Please see http://bugs.slimdevices.com/show_bug.cgi?id=6806. Basically, if there is no explicit difference between "Make this play what that has" and "Make that play what this has" I expect my actions to only *change* the player I'm closest to. It's presumptious for my IR interaction to force a change on a player I can't even see. Is my dog napping in front of the speaker? Is my wife putting away the crystal pitcher?

Your first scenario sounds right to me, but for different reasons. With the Controller, there's no direct relationship between the controller and my physical location. I could easily walk into the SB3 room and check out the situation before "pushing" the Controller's playlist onto the SB3.

The IR interface is all about where you are. The Controller interface is all about what you're listening to.

I don't mean to defend the status quo. I think the ideal solution would
1) use language to make it clear what you're doing (push/pull, control/follow, etc.)
2) allow both push and pull use cases from all interfaces (IR, Controller, Web).

Our disagreement about what should happen with the IR remote is a good illustration of why the system ought to allow both options. The fact this thread exists is evidence that the current language could be improved.

Dean B. has made it clear that there's a lot of UI work going on in Logitech. I expect the UI designers are testing their own private changes to the sync UI, and simply haven't got their improvements polished up enough just yet to release them to the rest of us.