This is a firmware/SqueezeCenter issue.

So we really want the button function to be sleep.*?  Won't that be confusing, function wise?  Or, is the plan to have it perform sleep functions as well as having the sleep button do the snooze function when the alarm goes?

I have a snooze feature in the extended alarm, so it's easy enough for me to add the feature to the existing alarm.

I think Dean would like to have the functionality like this:

- If no alarm is currently going off and the player is turned on, act as sleep button and turn player off in 15, 30, ... minutes.

- If alarm is sounding, act as snooze button and delay alarm for a couple of minutes.

That's right, per the UI spec on wiki-corp.  :)

That said, I finally got a unit with a working snooze bar and it's really really too easy to accidentally press it when picking up the remote.

I propose that the bar only be a sleep button with press-hold to avoid this.

I don't understand.  You want sleep to be something you can accidentally trigger, but have press-hold for snooze?  Or do you mean having snooze easy to activate, but sleep function as a press and hold?

No, I want Snooze to be something easy to do when the alarm goes off and you are half asleep.

I want Sleep to be something a bit harder and require explicit pressing on the bar.  

The button on the remote should remain easy for both cases.

ok, so this may need a slight change in button naming.  Since front panel uses .down-.up to map to do a full button map, we have the following:

Alarm Active:
front panel 'sleep' - snooze for 10 mins
remote 'sleep' - snooze for 10 mins

No Alarm:
front panel 'sleep.hold' - sleep
front panel 'sleep' - do nothing
remote 'sleep' - sleep

That last pair are the problem, as we don't know the source of the button, just the name.  So I propose renaming the front panel to 'snooze' so we have:

'sleep' or 'snooze' when alarm active - snooze for 10
'sleep' or 'snooze.hold' when no alarm - do sleep functions.

The next question is, do we want 'snooze' available for x minutes after the alarm is triggered (ie, I'll set a function callback on trigger, then clear it some time later), or should we work similarly to RandomPlay where once the alarm is triggered, we stay in "alarm active" state until one of the %stopCommands are issued?  

In the Alarm Plugin, the alarm is a completely different button mode, so alarm active features end when the user interacts in any way that takes you out of that mode.  The built in alarm, simply jumps to playing mode.

oh yeah, meant to ask...wiki-corp? Is that what the naming implies - internal coporate wiki therefore useless to folks like me?  Gives me an excuse to ask questions already answered ;)

Your description is good, and yes, the snooze button shouldn't do anything when snoozing, until the alarm goes off again.

Re: wiki-corp, Yeah, sorry that server isn't open.  I can send you the contents of that page, tho.

Created attachment 3225 [details]
very rough patch

rough patch done on 7.0 trunk (so no connection with the real snooze button).  This borrows the 0 button from the remote as a simulation.  I'm not sure the modeParam active flag will be enough, but it works for proof of concept.  It can be a tricky feature to implement since it is context sensitive based on events rather than states.

Created attachment 3227 [details]
specifically for boom

sorry for being so quiet.  much to do even though we're fully relocated.  This one remaps the boom button and seems to work.  Needs testing and hardening.  I still think it will need a callback, but that will be part of hardening.

initial version in change 18841

See also #7904 which maps a single press to briefly show the time.

useless comment to the link to bug 7904, as I seem to have trouble finding it in searches.

Chris to see if snooze works well enough

I'm actually about to change the way it works.  See Bug 7946.

Hey Max -- your description has piqued the interest of some people here, and they're anxious to try it out. Any chance we'll be able to check it out soon?

Thanks!

Which bit?  The changes to time input are all done and checked in to the Boom branch.  I'm doing the changes to the alarm itself at the moment.

See Bug 8183 for feedback on active snooze.

At the moment an active alarm is cancelled (but playback continues!) upon any activity other than sleep or snooze.  A snooze can only be started when an alarm is active.  This means that if the user does anything other than press sleep or snooze after an alarm starts, they can't then start a snooze.  Any activity apart from sleep/snooze during a snooze cancels the snooze.  This behaviour is temporary - we  need to decide what it should be.

Snooze button now successfully schedules a snooze during an alarm.  During a snooze anything that starts music playing again cancels the snooze and the alarm.  Alarms (and therefore snoozes) are cancelled by anything that stops the music.

During an alarm/snooze the snooze button also pushes into the datetime screensaver (bug 8183).

Re-open if anyone is still having an issue with the snooze bar not working (that is not explainable by hoopty hardware)

I think our Snooze button still acts funny... I like that it takes 1-2 seconds of holding the bar down to get it to respond the first time, but once its up you should be able to quickly tap to skip from 15Min to 30 to 45 to 60 to 90 to Off without having to hold it down two seconds each time. 

Anyone else disagree? 

The snooze button does not function at all, to snooze an alarm, with the latest new-streaming 7.2 as of this morning (7/22) via an SVN update done late last night (7/21).

It's not the snooze button that's the problem.  In the new streaming branch, extra stop events get generated from S::P::StreamingController.  These cause the alarm to stop straight after it sounds, so it's no longer valid to snooze an alarm because it's no longer active.  Not ideal.  ;-)

Can we assign this a priority?

Snoozebar functionality is important for launch.

Mike

We won't punt this.  Andy's covering the new streaming work for the time being.

Please mark new streaming bugs appropriately.  This means new_streaming keyword or, if non-Boom, product 7.2-new-streaming.

Fixed in change 22073.  Most likely this fix will break something else.

Re-opening so someone can address comment #24.  This bug could maybe do with splitting out.

I split Matt's comment 24 about the duration of the button press to bug 8860.

Verified fix 7.2-22579 r26.  Snooze bar now functions as designed

As Alan has fixed what Andy's patch broke, this issue is back, now reported as bug 11582