Bugzilla – Bug 9329
Alarm: Make alarm volume and duration configurable per alarm
Last modified: 2012-02-09 05:41:29 UTC
With kdf's Extended Alarm Plugin now deprecated I would like to see some of the plugin's useful features in the new alarm. Alarm volume and alarm duration should be configurable per alarm and not just globally for all alarms. If different alarms on one Squeezebox are used by different people it can be preferrable to have different alarm volumes on different alarms. A light sleeper needs a lower volume to wake up vs. a sound sleeper who needs a loud alarm to get out of bed. Alarm duration is also likely to depend on the persons habits. Someone who stays in bed for some time after waking up needs a longer duration than someone who gets up instantly when the alarm goes off.
Volume already is configurable per-alarm, but there's no ui for it. You can set an alarm's volume individually by editing it in the prefs file or using the cli. The ui used to have per-alarm volume settings, but it made for a lot of settings. Sounds like a pref to enable advanced alarm settings might be called for, but it's a bit of a ui cludge. Duration per-alarm is not possible atm.
Dean, could you help target this? Or should we just let it alone to accumulate votes and comments?
*** Bug 9609 has been marked as a duplicate of this bug. ***
I use KDF's extended alarm plugin as well and keep having to hack at it to keep it running. I have 2 SB3's (one in bedroom and one attached to stereo), each of which alarms at different times each day. I use different volume settings for each SB and each alarm has a different duration (some end after various set amounts of time, some don't end at all). Until the Alarm Clock supports individual volume and duration (specific duration or no specific timeout), the Alarm Clock really isn't a replacement for KDF's plugin. KDF did such a nice job with functionality, it's shame that the level of functionalty he created hasn't made it into the only other game in town.
I would very much like to be able to configure alarm volume per alarm. Duration would be helpful too.
volume configurable per alarm would be very useful. thanks.
Is there any idea as to when this might be dealt with? As there is no real substitute for the now-deprecated KDF Extended Alarm plugin, it strikes me that this is a bit bigger than a "future enhancement". While I realize that your priorities center around playing media and such, this is a serious functionality issue, that impacts the usefulness of the device to a potential audience beyond audio enthusiasts. It seems to go toward the heart of device utility. I'd just like some idea of when I can stop babying the old KDF plugin to keep it working. Months? Years? Never? Just setting a target version for inclusion would be a blessing. Thanks! Aside from this one issue, I'm extremely satsified with the SB#/Squeezecenter platform. Our household literally "lives" on it for access to Public Radio (we're in a fringe area without receivable "over the air" stations. Running on a old Celeron machine with Debian Lenny, it's a solid, stable delivery platform.
Created attachment 5103 [details] Implement API and CLI for per-alarm timeout plus other bits Dean decided originally that allowing per-alarm volume in the ui made things too complex. I'm not proposing to change this decision now. However, the alarm code has always supported per-alarm volumes and these could be set via plugin code or the CLI. The attached patch also implements per-alarm timeout settings, again settable through code or the API. See the docs in Slim::Utils::Alarm.pm for details, and also the CLI docs. None of this is exposed in the default user interface. This patch also adds the ability to query whether an alarm uses the default volume/timeout via the CLI by adding to new tagged parameters to the alarms query - usesDefaultVolume and usesDefaultTimeout. Additionally, it allows you to change an alarm back to using the default volume/timeout via the cli alarm command by setting the timeout or volume parameter to -. Again, see CLI docs for more info. I'd like to check this patch into 7.4, but am unsure of the status of the 7.4 branch. Please advise if it's safe to do this. Tim: rather than spend time keeping KDF's deprecated alarm plugin going, I'd advise you consider writing a plugin to expose this new functionality in the user interface. Alternately, you could use the functionality via the CLI or possibly the http interface. We could consider adding these into the standard ui via, possibly enabled via a 'enable advanced alarm settings' pref. However, I'm going to leave that decision to Dean et al. An alternative may be to modify the alarm code to allow plugins to extend it with the addition of extra sub-menus. This may already be possible with the Controller interface to the alarms.
(In reply to comment #8) I'd be happy to if I were a good enough programmer. I barely understand Perl and KDF's plugin well enough to deal with the problems that crop up with each SC update (mainly keeping alarms in the schedule). Otherwise, I'd be happy to help and would have already submitted something... Thanks! > Created an attachment (id=5103) [details] > Implement API and CLI for per-alarm timeout plus other bits > > Dean decided originally that allowing per-alarm volume in the ui made things > too complex. I'm not proposing to change this decision now. However, the > alarm code has always supported per-alarm volumes and these could be set via > plugin code or the CLI. The attached patch also implements per-alarm timeout > settings, again settable through code or the API. See the docs in > Slim::Utils::Alarm.pm for details, and also the CLI docs. None of this is > exposed in the default user interface. > > This patch also adds the ability to query whether an alarm uses the default > volume/timeout via the CLI by adding to new tagged parameters to the alarms > query - usesDefaultVolume and usesDefaultTimeout. Additionally, it allows you > to change an alarm back to using the default volume/timeout via the cli alarm > command by setting the timeout or volume parameter to -. Again, see CLI docs > for more info. > > I'd like to check this patch into 7.4, but am unsure of the status of the 7.4 > branch. Please advise if it's safe to do this. > > Tim: rather than spend time keeping KDF's deprecated alarm plugin going, I'd > advise you consider writing a plugin to expose this new functionality in the > user interface. Alternately, you could use the functionality via the CLI or > possibly the http interface. > > We could consider adding these into the standard ui via, possibly enabled via a > 'enable advanced alarm settings' pref. However, I'm going to leave that > decision to Dean et al. An alternative may be to modify the alarm code to > allow plugins to extend it with the addition of extra sub-menus. This may > already be possible with the Controller interface to the alarms.
*** This bug has been marked as a duplicate of bug 3170 ***
This is not a duplicate of bug 3170.
*** Bug 11971 has been marked as a duplicate of this bug. ***
This bug needs to be reopened - it is not a duplicate of 3170. Bug 3170 deals with a single alarm volume being increased over time. This bug deals with multiple alarms having different volume levels. Please reopen and remove duplicate tag.
Well stated, removing duplicate tag Max: is your patch working should we check it into 7.5 to get some eyes on it?
I believe my patch is working. It certainly was when I wrote it, and I've had it in my local copy since then. I don't use this feature myself, however, so this only tells you that it doesn't cause the server to obviously break. Should be fine to check into 7.5 if you want it.