PDA

View Full Version : [slim] Re: Player stopping rather than pausingwhen switched off?



Triode
2005-09-02, 11:12
Thought I've move this discussion to the dev list as there are a couple of things to sort out now I've looked a the code more:

At present the pause/stop and unsync action occurs in the Buttons/Power.pm aka 'off' setMode. The resync action occurs in
$client->power. Now I believe these can be treated as the same as only $client>power pushes into mode 'off' and pops out of it,
hence I'd like to amalgamate the logic for this.

So:
1) Does anything other than $client->power set the mode to 'off' (I can't find anything). If not I propose to move all the logic to
$client->power rather than have half in each place...

2) How should this functionality co-exist with synchonisation. At present if syncPower is 0 the player is unsynced and put into
"stop" mode on power off. On power on, the player is always sychronised if necessary. I can keep this logic and hence bypass the
setting for sychronised players?

3) Thanks for Michael raising it - what does autoPlay do and where is the pref actually set????? I assume this can be deleted?

Adrian

----- Original Message -----
From: "Michael Herger" <slim (AT) herger (DOT) net>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Friday, September 02, 2005 5:14 AM
Subject: Re: [slim] Re: Player stopping rather than pausing when switched off?


>> Power Off / Resume mode:
>> 1) Pause/Resume: Power off = pause, power on = unpause - continue playing same track at point paused.
>
> Hey, will this finally be the user interface to the autoPlay setting?!? Wow! Great news! I already thought I'd write a plugin for
> it :-)
>
> --
>
> Michael
>
> -----------------------------------------------------------
> Help translate SlimServer by using the
> StringEditor Plugin (http://www.herger.net/slim/)
>

dean
2005-09-02, 12:45
On Sep 2, 2005, at 11:12 AM, Triode wrote:

> Thought I've move this discussion to the dev list as there are a
> couple of things to sort out now I've looked a the code more:
>
> At present the pause/stop and unsync action occurs in the Buttons/
> Power.pm aka 'off' setMode. The resync action occurs in $client-
> >power. Now I believe these can be treated as the same as only
> $client>power pushes into mode 'off' and pops out of it, hence I'd
> like to amalgamate the logic for this.
>
> So:
> 1) Does anything other than $client->power set the mode to 'off' (I
> can't find anything). If not I propose to move all the logic to
> $client->power rather than have half in each place...
Sounds good.

>
> 2) How should this functionality co-exist with synchonisation. At
> present if syncPower is 0 the player is unsynced and put into
> "stop" mode on power off. On power on, the player is always
> sychronised if necessary. I can keep this logic and hence bypass
> the setting for sychronised players?
I'm not following.


>
> 3) Thanks for Michael raising it - what does autoPlay do and where
> is the pref actually set????? I assume this can be deleted?
It was initially added for our testing of squeezeboxes here. Please
don't take it out, but if you'd like to add a UI to it...

Triode
2005-09-02, 14:00
> I'm not following.
>

The issue was whether the new logic should apply to synchonised players as well.

I've got the following options at present:

'PauseOff-NoneOn' => string('SETUP_POWERONRESUME_PAUSEOFF_NONEON')
,'PauseOff-PlayOn' => string('SETUP_POWERONRESUME_PAUSEOFF_PLAYON')
,'StopOff-PlayOn' => string('SETUP_POWERONRESUME_STOPOFF_PLAYON')
,'StopOff-NoneOn' => string('SETUP_POWERONRESUME_STOPOFF_NONEON')
,'StopResetOff-NoneOn' => string('SETUP_POWERONRESUME_STOPRESETOFF_NONEON')
,'StopResetOff-PlayOn' => string('SETUP_POWERONRESUME_STOPRESETOFF_PLAYON')

The action on power off is "pause", "stop" or "stop & reset playlist index"
The action on power on is nothing or "play"

The issue is how this co-exisits with sychronisation and does it matter if strange things occur if the preference is set differently
for different players in a sync group?

For the off case, if syncPower is not set then the player is taken out of the sync group and put in the "stop" state - there is no
real option to do anything else here.
When the last player in a synch group is powered off it would follow the normal action and hence options above - i.e. allow pause,
stop or stop&reset.
If syncPower is set, then all players are turned off, but each player would follow the normal action and be put into a different
"stop" or "pause" mode depending on the setting of this pref.

When a player is powered on it is synchonised with other players in the group. If it is the first player to be powered on it is
valid to allow the "play" action if set in the pref.
But if synchPower is set they will all power on together - in this case it is effectively random which player actually has
$client->power(1) run first. I think what happens will depend on the pref setting for this player...

So I conclude that if a syncPower is set then this preference really ought to be the same for all players in the group? Ether that
or it should be ignored in some way?

dean
2005-09-02, 14:36
On Sep 2, 2005, at 2:00 PM, Triode wrote:
> The issue was whether the new logic should apply to synchonised
> players as well.
It should.

> I've got the following options at present:
>
> 'PauseOff-NoneOn' => string('SETUP_POWERONRESUME_PAUSEOFF_NONEON')
> ,'PauseOff-PlayOn' => string('SETUP_POWERONRESUME_PAUSEOFF_PLAYON')
> ,'StopOff-PlayOn' => string('SETUP_POWERONRESUME_STOPOFF_PLAYON')
> ,'StopOff-NoneOn' => string('SETUP_POWERONRESUME_STOPOFF_NONEON')
> ,'StopResetOff-NoneOn' => string
> ('SETUP_POWERONRESUME_STOPRESETOFF_NONEON')
> ,'StopResetOff-PlayOn' => string
> ('SETUP_POWERONRESUME_STOPRESETOFF_PLAYON')
>
> The action on power off is "pause", "stop" or "stop & reset
> playlist index"
> The action on power on is nothing or "play"
>
> The issue is how this co-exisits with sychronisation and does it
> matter if strange things occur if the preference is set differently
> for different players in a sync group?
>
> For the off case, if syncPower is not set then the player is taken
> out of the sync group and put in the "stop" state - there is no
> real option to do anything else here.
> When the last player in a synch group is powered off it would
> follow the normal action and hence options above - i.e. allow pause,
> stop or stop&reset.
> If syncPower is set, then all players are turned off, but each
> player would follow the normal action and be put into a different
> "stop" or "pause" mode depending on the setting of this pref.
>
> When a player is powered on it is synchonised with other players in
> the group. If it is the first player to be powered on it is
> valid to allow the "play" action if set in the pref.
> But if synchPower is set they will all power on together - in this
> case it is effectively random which player actually has
> $client->power(1) run first. I think what happens will depend on
> the pref setting for this player...
>
> So I conclude that if a syncPower is set then this preference
> really ought to be the same for all players in the group?
Yes. But you are right in saying that the behavior is undefined if
the players have different settings. Just pick one, I'd say,
probably the master's. Users may need to go into their settings and
adjust the behavior in that case. Most users won't have this issue
as they won't change the default.

Triode
2005-09-02, 16:28
How about the attached - handles the sync case by telling the user to set all players to the same preference!

Includes moving a bit of the power off display code out of Slim/Buttons/Power.pm

Do I have the right set of options - it's changed slightly from the ones discussed before.

Adrian

dean
2005-09-02, 17:01
Nope, that won't do. Don't make the users do the work! :)

How about looking for a sync group setting for this behavior (indexed
by the sync group id) and use that. If the user changes it for one
player in the group, update that group's setting.

If a player leaves the group, it defaults to its own setting, if a
new one joins, it gets to start using the group's setting.

(To populate the initial group setting, use the master's setting.
That's the best we can guess.)



On Sep 2, 2005, at 4:28 PM, Triode wrote:

> How about the attached - handles the sync case by telling the user
> to set all players to the same preference!
>
> Includes moving a bit of the power off display code out of Slim/
> Buttons/Power.pm
>
> Do I have the right set of options - it's changed slightly from the
> ones discussed before.
>
> Adrian
> <resume.diff>
>

Triode
2005-09-03, 12:23
OK try this.... hopefully something similar to Dean's proposal....

I've added the concept of a syncGroupPref - this is used to store a pref for the whole sync group and I would value feedback on
whether this is compatible with the new method of calling prefs. The idea is that you check it first before client pref to get the
active pref for the group or player:

my $resumePref = Slim::Player::Sync::syncGroupPref($client, 'powerOnResume') || $client->prefGet('powerOnResume');

Now to make this work I've modified slightly the way sync prefs are saved and would like some feedback on this. Specifically I
delete the sync group for both players when unsyncing two players in a sync group [before one was left in a group of one]. This
allows the syncGroupPref to be deleted at this point.

As for the actual power on/off behaviour, I'm happy with this for the unsynced case, but for the synced case I would be keen on
feedback as to how this works for people [I've not used sync before and seem to have some difficulty between softsqueeze and a
squeezebox here.] Other than changing the sync pref storage and potentially playing the first player in group at power up, I would
hope sync works as before..?

Adrian

----- Original Message -----
From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Saturday, September 03, 2005 1:01 AM
Subject: Re: [Developers] Fw: [slim] Re: Player stopping ratherthanpausingwhen switched off?


> Nope, that won't do. Don't make the users do the work! :)
>
> How about looking for a sync group setting for this behavior (indexed by the sync group id) and use that. If the user changes it
> for one player in the group, update that group's setting.
>
> If a player leaves the group, it defaults to its own setting, if a new one joins, it gets to start using the group's setting.
>
> (To populate the initial group setting, use the master's setting. That's the best we can guess.)

Triode
2005-09-09, 16:10
Did anyone have a chance to look at this? I'm particularly interested in comments on the sync group wide preference and the impact
on the sync code.

Adrian

[I can repost the patch against a newer subversion if appropriate]
----- Original Message -----
From: "Triode" <triode1 (AT) btinternet (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Saturday, September 03, 2005 8:23 PM
Subject: Re: [Developers] Fw: [slim] Re: Player stopping ratherthanpausingwhenswitched off?


> OK try this.... hopefully something similar to Dean's proposal....
>
> I've added the concept of a syncGroupPref - this is used to store a pref for the whole sync group and I would value feedback on
> whether this is compatible with the new method of calling prefs. The idea is that you check it first before client pref to get
> the
> active pref for the group or player:
>
> my $resumePref = Slim::Player::Sync::syncGroupPref($client, 'powerOnResume') || $client->prefGet('powerOnResume');
>
> Now to make this work I've modified slightly the way sync prefs are saved and would like some feedback on this. Specifically I
> delete the sync group for both players when unsyncing two players in a sync group [before one was left in a group of one]. This
> allows the syncGroupPref to be deleted at this point.
>
> As for the actual power on/off behaviour, I'm happy with this for the unsynced case, but for the synced case I would be keen on
> feedback as to how this works for people [I've not used sync before and seem to have some difficulty between softsqueeze and a
> squeezebox here.] Other than changing the sync pref storage and potentially playing the first player in group at power up, I
> would
> hope sync works as before..?
>
> Adrian
>
> ----- Original Message -----
> From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
> Sent: Saturday, September 03, 2005 1:01 AM
> Subject: Re: [Developers] Fw: [slim] Re: Player stopping ratherthanpausingwhen switched off?
>
>
>> Nope, that won't do. Don't make the users do the work! :)
>>
>> How about looking for a sync group setting for this behavior (indexed by the sync group id) and use that. If the user changes
>> it
>> for one player in the group, update that group's setting.
>>
>> If a player leaves the group, it defaults to its own setting, if a new one joins, it gets to start using the group's setting.
>>
>> (To populate the initial group setting, use the master's setting. That's the best we can guess.)
>


--------------------------------------------------------------------------------


>

dean
2005-09-09, 16:19
Sorry, I think it looks good, although I'd like to see it in the
nightly and test it with multiple players here.

Go for it.

-dean


On Sep 9, 2005, at 4:10 PM, Triode wrote:

> Did anyone have a chance to look at this? I'm particularly
> interested in comments on the sync group wide preference and the
> impact on the sync code.
>
> Adrian
>
> [I can repost the patch against a newer subversion if appropriate]
> ----- Original Message ----- From: "Triode" <triode1 (AT) btinternet (DOT) com>
> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
> Sent: Saturday, September 03, 2005 8:23 PM
> Subject: Re: [Developers] Fw: [slim] Re: Player stopping
> ratherthanpausingwhenswitched off?
>
>
>
>> OK try this.... hopefully something similar to Dean's proposal....
>>
>> I've added the concept of a syncGroupPref - this is used to store
>> a pref for the whole sync group and I would value feedback on
>> whether this is compatible with the new method of calling prefs.
>> The idea is that you check it first before client pref to get the
>> active pref for the group or player:
>>
>> my $resumePref = Slim::Player::Sync::syncGroupPref($client,
>> 'powerOnResume') || $client->prefGet('powerOnResume');
>>
>> Now to make this work I've modified slightly the way sync prefs
>> are saved and would like some feedback on this. Specifically I
>> delete the sync group for both players when unsyncing two players
>> in a sync group [before one was left in a group of one]. This
>> allows the syncGroupPref to be deleted at this point.
>>
>> As for the actual power on/off behaviour, I'm happy with this for
>> the unsynced case, but for the synced case I would be keen on
>> feedback as to how this works for people [I've not used sync
>> before and seem to have some difficulty between softsqueeze and a
>> squeezebox here.] Other than changing the sync pref storage and
>> potentially playing the first player in group at power up, I would
>> hope sync works as before..?
>>
>> Adrian
>>
>> ----- Original Message ----- From: "dean blackketter"
>> <dean (AT) slimdevices (DOT) com>
>> To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
>> Sent: Saturday, September 03, 2005 1:01 AM
>> Subject: Re: [Developers] Fw: [slim] Re: Player stopping
>> ratherthanpausingwhen switched off?
>>
>>
>>
>>> Nope, that won't do. Don't make the users do the work! :)
>>>
>>> How about looking for a sync group setting for this behavior
>>> (indexed by the sync group id) and use that. If the user
>>> changes it
>>> for one player in the group, update that group's setting.
>>>
>>> If a player leaves the group, it defaults to its own setting, if
>>> a new one joins, it gets to start using the group's setting.
>>>
>>> (To populate the initial group setting, use the master's
>>> setting. That's the best we can guess.)
>>>
>>
>>
>
>
> ----------------------------------------------------------------------
> ----------
>
>
>
>>