PDA

View Full Version : State of sync in 7.1



max.spicer
2008-04-06, 08:35
I'm seeing quite a few bugs with syncing in 7.1 at the moment. I can't select players to sync with programatically or through the web ui unless they are currently turned on. Players are turning up multiple times in the Settings->Synchronize mode. Is the code currently under work, or should I file some bugs / think about fixes?

Max

awy
2008-04-09, 05:05
There have been some changes but no more specific changes are planned at present.

Once change is that syncing with an 'off' player does not sort-of half turn it on.

But there is still stuff missing: the isSyncedWith and canSyncWith functions need variations which allow for them being off. Sometimes the question is asked in the code and only 'on' players should be included but in other cases all players should be included. It is quite a mess. (bug 7531).

I do not understand the bit about "Players are turning up multiple times in the Settings->Synchronize mode".

max.spicer
2008-04-09, 09:05
There have been some changes but no more specific changes are planned at present.

Once change is that syncing with an 'off' player does not sort-of half turn it on.

But there is still stuff missing: the isSyncedWith and canSyncWith functions need variations which allow for them being off. Sometimes the question is asked in the code and only 'on' players should be included but in other cases all players should be included. It is quite a mess. (bug 7531).

I do not understand the bit about "Players are turning up multiple times in the Settings->Synchronize mode".

I found that the list of players I could sync with included duplicates.

On a different note, is mid-track join ever on the horizon? I've got a player in every room now and often wander round the house listening to music e.g. while dusting. It's really disrupting to others in the house that every time I turn a player on when entering a new room it restarts all the others.

Max

Millwood
2008-04-09, 09:34
On a different note, is mid-track join ever on the horizon? I've got a player in every room now and often wander round the house listening to music e.g. while dusting. It's really disrupting to others in the house that every time I turn a player on when entering a new room it restarts all the others.

Max

Agree. And it would, IMHO, be good enough to restart the track positioned about where it was - I can tolerate a hickup. It would seem that the positioning mechanism of the scanner ought to be good enough to do that.

peterw
2008-04-09, 10:15
Agree. And it would, IMHO, be good enough to restart the track positioned about where it was - I can tolerate a hickup. It would seem that the positioning mechanism of the scanner ought to be good enough to do that.

Take a look at my SyncOptions plugin, which uses the SongScanner positioning techniques. It provides mid-song joining/resyncing options for local MP3 and FLAC tracks. It can always resync everyone at about where the master/group was (with a slight hiccup), or it can have the joiner by default wait for the next track but, if it has an IR remote, allow you to press one button to resync the whole group about where the master/group iss ("sync up") or press another button to make them all "restart [the] track".
http://www.tux.org/~peterw/slim/SyncOptions.html

-Peter

max.spicer
2008-04-12, 03:32
There have been some changes but no more specific changes are planned at present.

Once change is that syncing with an 'off' player does not sort-of half turn it on.

But there is still stuff missing: the isSyncedWith and canSyncWith functions need variations which allow for them being off. Sometimes the question is asked in the code and only 'on' players should be included but in other cases all players should be included. It is quite a mess. (bug 7531).

I've just been having a look at this. You also need a variant of syncedWith() that returns all players with the same syncgroupid pref. The thing I would need to know before trying to fix this is what is the expected behaviour of Slim::Control::Query::syncQuery(). Should it only return players that are actually synced (i.e. same sync group and on) or should it return all players with the same sync group? If the former, then there will assumedly need to be a variant of this as well.

I'm happy to do some work on this if people can provide the necessary info.

Max

awy
2008-04-18, 23:35
Agree. And it would, IMHO, be good enough to restart the track positioned about where it was - I can tolerate a hickup. It would seem that the positioning mechanism of the scanner ought to be good enough to do that.

I'll probably add that for SC 7.1. It should also work for remote streams, like podcasts, that support seeking (but not transcoded ones).

awy
2008-04-18, 23:44
I've just been having a look at this. You also need a variant of syncedWith() that returns all players with the same syncgroupid pref. The thing I would need to know before trying to fix this is what is the expected behaviour of Slim::Control::Query::syncQuery(). Should it only return players that are actually synced (i.e. same sync group and on) or should it return all players with the same sync group? If the former, then there will assumedly need to be a variant of this as well.

I'm happy to do some work on this if people can provide the necessary info.

Max

The trouble is that some calls expect just the on players and some would (ideally) like all players in the group. See bug 7531 (http://bugs.slimdevices.com/show_bug.cgi?id=7531). I do not think that this is easy to get right and there is a lot of possibility of breaking things.

I am wondering if my previous fix (bug 7171 (http://bugs.slimdevices.com/show_bug.cgi?id=7121), change 17897), which allowed to sync with an off player with out turning it half on, should be reverted. Possibly replacing it with one which turns the 'other' player fully on if need be.

max.spicer
2008-04-19, 02:02
I'll probably add that for SC 7.1. It should also work for remote streams, like podcasts, that support seeking (but not transcoded ones).

That would be fantastic! Adding players to playing sync groups is just too intrusive at the moment.

Max

max.spicer
2008-04-19, 02:36
The trouble is that some calls expect just the on players and some would (ideally) like all players in the group. See bug 7531 (http://bugs.slimdevices.com/show_bug.cgi?id=7531). I do not think that this is easy to get right and there is a lot of possibility of breaking things.

So why not just add the variants? I wouldn't have thought it would be that hard to track down which call is which. When choosing which player to sync with, you want all players in a group. What are the other times?

I am wondering if my previous fix (bug 7171 (http://bugs.slimdevices.com/show_bug.cgi?id=7121), change 17897), which allowed to sync with an off player with out turning it half on, should be reverted. Possibly replacing it with one which turns the 'other' player fully on if need be.[/QUOTE]

I think that would be a mistake. I often leave players synced, but keep some of them off. I would not want them to all turn on. Ideally, if a player is in a sync group but is off, it should be fully off, but turning it on would immediately bring it in sync with any other playing players in the group.

Max