PDA

View Full Version : SS <-> SN pref syncing now in trunk



andyg
2007-07-05, 15:18
Continuing on the theme of better SS/SN integration in SS7, I've just
checked in pref syncing. If you enter your SN login details in
Server Settings -> SqueezeNetwork, pref changes made while a player
is on SlimServer will be sent to SN and vice versa.

http://svn.slimdevices.com/?rev=12348&view=rev

Please test, etc, feedback is welcome as always.

peterw
2007-07-05, 17:30
Sounds like very good progress!

Please pardon my laziness for posting without RTFCode in depth. Am I reading
http://svn.slimdevices.com/trunk/server/Slim/Utils/Prefs.pm?rev=12348&view=markup
right that screensaver (screensaver/offsaver/idlesaver) preferences are not synced?

I'm interested in this because currently SaverSwitcher changes screenavers by changing a player's screensaver/offsaver/idlesaver preference.[0] Syncing with SN brings up a couple issues: 1) I wouldn't really want SlimServer syncing prefs with SN every time SaverSwitcher decides to change the screensaver and 2) I wonder how the sync deals with incompatible choices. E.G, if my offsaver is SuperDateTime and that's not available on SN, what happens with a Slimserver -> SN pref sync? If I choose DateTime on SN, would that change my local Slimserver offsaver pref?

Thanks,

Peter

[0] not ideal, but I haven't had much time to work on using pushMode/popMode instead of changing the prefs

andyg
2007-07-05, 17:48
On Jul 5, 2007, at 8:30 PM, peterw wrote:

>
> Sounds like very good progress!
>
> Please pardon my laziness for posting without RTFCode in depth. Am I
> reading
> http://svn.slimdevices.com/trunk/server/Slim/Utils/Prefs.pm?
> rev=12348&view=markup
> right that screensaver (screensaver/offsaver/idlesaver) preferences
> are
> not synced?

The list of synced preference is actually obtained from SN during
init, and is currently this list:

activeFont
activeFont_curr
alarm
alarmfadeseconds
alarmtime
alarmvolume
autobrightness
digitalVolumeControl
disabledirsets
idleBrightness
idleFont
idleFont_curr
idlesaver
maxWMArate
offsaver
playername
playingDisplayMode
playtrackalbum
preampVolumeControl
power
powerOffBrightness
powerOnBrightness
screensaver
screensavertimeout
scrollMode
transitionDuration
transitionType
visualMode
volume
webproxy

You bring up a good point, the SN side needs to validate all values
of prefs before storing them.

One set of prefs I'm not sure about are the alarm prefs. It's
currently syncing all the alarm data except for alarmplaylist,
because on SN this is a radio stream, and on SS it's local music.

peterw
2007-07-06, 05:44
Here's another approach: push the sync question to the UI layer.

I have a few Squeezeboxes. I generally use the same settings on all of them. A couple have different brightess settings, and of course they have unique names, but otherwise they use the same settings. Recently I added Replay Gain tags to all my music. I then had to use the web UI N different times to enable RG on my N different squeezeboxes. It would be nice if the UIs (especially the web UI) allowed me the choice of applying a change to one Squeezebox, to some or all Squeezeboxes that support the change, to SN, or some combination.

This might help with pref syncing. Instead of always trying to keep prefs in sync (which assumes users want everything kept in sync), have the web UI ask the user where to apply the changes. Make the UI smart enough to default to pre-selecting the same set of players that the user applied the last change to.

-Peter

andyg
2007-07-06, 05:51
On Jul 6, 2007, at 8:44 AM, peterw wrote:

>
> Here's another approach: push the sync question to the UI layer.
>
> I have a few Squeezeboxes. I generally use the same settings on all of
> them. A couple have different brightess settings, and of course they
> have unique names, but otherwise they use the same settings.
> Recently I
> added Replay Gain tags to all my music. I then had to use the web UI N
> different times to enable RG on my N different squeezeboxes. It would
> be nice if the UIs (especially the web UI) allowed me the choice of
> applying a change to one Squeezebox, to some or all Squeezeboxes that
> support the change, to SN, or some combination.
>
> This might help with pref syncing. Instead of always trying to keep
> prefs in sync (which assumes users want everything kept in sync), have
> the web UI ask the user where to apply the changes. Make the UI smart
> enough to default to pre-selecting the same set of players that the
> user applied the last change to.

I think it's best to have it 'just work' and not confuse the user
with options like that. And I think most prefs that are synced are
not changed via the web UI.

sbjaerum
2007-07-08, 00:29
When I change the font size on SN, and then switch to SS, I see in the pref file that the font size set on SN is synced down to SS. However, the change is not executed in SS, I have to power the player off and then back on to get the same font size as on SN. Looks like some sort of trigger mechanism is missing?

Triode
2007-07-08, 01:48
When I change the font size on SN, and then switch to SS, I see in the pref file that the font size set on SN is synced down to SS. However, the change is not executed in SS, I have to power the player off and then back on to get the same font size as on SN. Looks like some sort of trigger mechanism is missing?

Probably due to caching in the display code - I'll have a look.

peterw
2007-07-08, 09:12
I think it's best to have it 'just work' and not confuse the user
with options like that. And I think most prefs that are synced are
not changed via the web UI.

It's clear that SS -> SN syncs should work if SS knows the SN login info, but prefs changed on SN won't sync back to SS unless the user is using SN through SS, right? Having a screen like I suggested would help users better understand how prefs would get out of sync when they're directly on SN.

If a player is using SN through SlimServer, which prefs are used? If my "screensaver" is MusicInfoScr and I'm using SN through SS, SN won't override my screensaver because it's not available on SN, right?

Another option for avoiding the annoyance of changing the same pref on N players: have a "default" player config object, and allow players to "inherit" the default player settings.

-Peter

P.S. I hope you don't think I'm being a nag. I almost never use SN, so the syncing part isn't a big issue for me. My main concerns are 1) SN -> SS syncs messing up screensaver prefs for SaverSwitcher users 2) understanding performance implications, as my SaverSwitcher plugin typically changes screensaver prefs several times per minute when a user is listening to music and 3) the possibility of addressing the "N prefs" problem that I've found quite annoying (especially for plugins like MusicInfoScr that have fairly elaborate setup options; one key reason that SaverSwitcher's 1-9/timing options are global is to avoid the nuisance of having to configure each of my Squeezeboxes separately).

peterw
2007-07-08, 13:16
My main concerns are
...
2) understanding performance implications, as my SaverSwitcher plugin typically changes screensaver prefs several times per minute when a user is listening to music
...

There may be an easy solution to that problem. If this SN sync behavior could be toggled on or off, I could have SaverSwitcher note the current "SN Pref Sync" pref before changing a player's saver preference, disable SN Pref Sync, change the player's saver pref, and then restore SN Pref Sync to the previously noted value. This would prevent SaverSwitcher from messing up SN syncs, and reduce network traffic and load on SN, too. Sound OK?

-Peter

andyg
2007-07-08, 17:44
It's clear that SS -> SN syncs should work if SS knows the SN login info, but prefs changed on SN won't sync back to SS unless the user is using SN through SS, right? Having a screen like I suggested would help users better understand how prefs would get out of sync when they're directly on SN.


If I get what you're asking, SN prefs are synced down only while the player is connected to SS. All changes made the last time that player was on SN are synced down as soon as it connects. I think this will work fine.



If a player is using SN through SlimServer, which prefs are used? If my "screensaver" is MusicInfoScr and I'm using SN through SS, SN won't override my screensaver because it's not available on SN, right?


There really isn't any such thing as "using SN through SS", all we have are several plugins that use services provided by SN such as Pandora, Rhapsody, and MP3tunes. When on SS, even while using these services, all prefs are SS prefs, not SN prefs. All 3rd party plugins will still work, etc. Try them out and see. :)

andyg
2007-07-08, 17:47
There may be an easy solution to that problem. If this SN sync behavior could be toggled on or off, I could have SaverSwitcher note the current "SN Pref Sync" pref before changing a player's saver preference, disable SN Pref Sync, change the player's saver pref, and then restore SN Pref Sync to the previously noted value. This would prevent SaverSwitcher from messing up SN syncs, and reduce network traffic and load on SN, too. Sound OK?

That won't work, timestamps still apply and the pref would still get synced. However, the validation on SN will cause any pref with an invalid value to be silently ignored. So you won't be able to mess up any prefs on the SN side. If you want to avoid the bit of extra traffic, you can force the timestamp to be wiped after you change the screensaver pref:

$prefs->client($client)->timestamp( $prefName, 'wipe' );

That will set it to '-1' and it won't be synced. But generally, I wouldn't worry about it too much.

peterw
2007-07-08, 19:19
'wipe' might do the trick, thanks.

I do need to worry. Typical SaverSwitcher usage is to cycle between a number of normal screensavers -- see http://www.tux.org/~peterw/slim/SaverSwitcher.html

So, in the example on that web page, both "active" savers (Now Playing and Date and Time) are going to be valid on SN, so without that wipe approach, SN would end up with Now Playing or Date and Time as the user's SN screensaver. A better example might be a user who has SaverSwitcher alternate between 20 seconds of MusicInfoScr and 5 seconds of Date and Time. The SN sync would always reject SaverSwitcher and MusicInfoScr, so the user would end up having SN think they wanted Date and Time. Not good. So if wiping the timestamp prevents SN sync, that's great.

Thank you.

sbjaerum
2007-07-09, 01:23
Probably due to caching in the display code - I'll have a look.

Your checkin 12362 fixed the issue.