Alarm: snapshot active volume at start to fix pre-alarm volume restore

[boudekerk]

Problem

For alarms that use the default volume (i.e. no per-alarm volume override), the restore check in stop() calls $self->volume dynamically. That method falls through to defaultVolume() which reads the alarmDefaultVolume preference live.

If the user changes the default alarm volume in settings while an alarm is active, $self->volume now returns a different value than the one that was set at alarm start. The guard condition:

if (! $client->isPlaying && $vol == $self->volume)

then fails, and the pre-alarm volume is never restored — even though the user never touched the player volume during the alarm.

Fix

Snapshot $self->volume into $self->{_activeVolume} in sound() and compare against that snapshot in stop(). The // fallback handles alarm objects that were created before this field existed.

This does not change behaviour when the user manually adjusts volume during an alarm: the current volume will differ from _activeVolume, so the restore is correctly skipped.

[michaelherger]

I don't follow. There's only one volume setting. There is no per-alarm setting, is there?

[boudekerk]

It looks like the per-alarm setting is simply not being exposed:

slimserver/Slim/Utils/Alarm.pm

Line 317 in 20b20dd

N.B. This feature is not exposed in the default interfaces. Alarms all use the default volume.

slimserver/Slim/Utils/Alarm.pm

Line 353 in 20b20dd

N.B. This feature is not exposed in the default interfaces. Alarms all use the default volume.

[michaelherger]

Thanks!