Skip to content

Alarm: add Dismiss option to Jive alarm popup#1564

Open
boudekerk wants to merge 1 commit intoLMS-Community:public/9.2from
boudekerk:feature/alarm-dismiss
Open

Alarm: add Dismiss option to Jive alarm popup#1564
boudekerk wants to merge 1 commit intoLMS-Community:public/9.2from
boudekerk:feature/alarm-dismiss

Conversation

@boudekerk
Copy link
Copy Markdown
Contributor

@boudekerk boudekerk commented May 2, 2026

Summary

  • Extends Slim::Utils::Alarm::stop() with an optional $continueAudio flag. When true, all player-state restores (analogOut, volume, shuffle, power) are skipped so playback continues uninterrupted.
  • The jivealarm command now accepts a continueAudio:1 parameter, forwarded to stop().
  • This wires up the new Dismiss menu item being added to the AlarmSnoozeApplet in the SqueezePlay client repos.

As a side-effect this also fixes the cancelAction (Back button on device) behaviour: the Lua client already sent stopAlarm(true) for Back, but the server was unconditionally restoring player state anyway.

Backward compatible: old clients that don't send continueAudio default to 0, preserving existing behaviour.

Related

Companion PRs (client side, independent):

Extends `stop()` with an optional `$continueAudio` flag.  When true,
all player-state restores (analogOut, volume, shuffle, power) are
skipped, leaving playback running while the alarm UI is dismissed.

The `jivealarm` command now accepts a `continueAudio:1` parameter which
is forwarded to `stop()`.  This wires up the new Dismiss menu item that
will be added to the AlarmSnoozeApplet on SqueezePlay/squeezeos clients.

As a side-effect this also fixes the `cancelAction` (Back button on
device) behaviour: the Lua client already called `stopAlarm(true)` for
Back, but the server was unconditionally restoring player state anyway.

Signed-off-by: Bartosz Oudekerk <lot+github@unreachablehost.net>
@michaelherger
Copy link
Copy Markdown
Member

Chicken and egg... I guess the other two PRs need this change to work? What if a user had the client side changes, but not this one?

@boudekerk
Copy link
Copy Markdown
Contributor Author

Chicken and egg... I guess the other two PRs need this change to work? What if a user had the client side changes, but not this one?

Server ignores the extra param. Same as stop effectively, no existing functionality touched, no harm done.

@boudekerk boudekerk marked this pull request as draft May 2, 2026 15:14
@boudekerk boudekerk marked this pull request as ready for review May 3, 2026 11:06
@michaelherger
Copy link
Copy Markdown
Member

I'm sorry, merged the other PR first - now this one is conflicting. Could you please resolve the conflicts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants