Looks like the code was broken in revision 7862 to address bug 14619 -- but r7862 appears to be overkill for the current codebase (see opening comment) -- with my proposed patch, I am able to shut down Radio even when there is an upcoming alarm. Perhaps bug 14619 was caused by some other alarm code that has been fixed by the work done recently by Ben and Marc -- so part of the r7862/bug 14619 checkin can (and should) now be removed?

The same problem exists in Radio firmware 7.5.0 r8594 with SBS 7.5.0 trunk r30395. Removing the setWakeupAlarm call as suggested in my patch seems good -- my patch does *not* trigger bug 14619 to recur, and does cause Radio to wake up before the upcoming alarm.

Steps to reproduce the problem
1) set an alarm for 5 minutes after the current time
2) make sure that alarm and "all alarms" are active
3) hold the power button for 2 seconds until you see the shutdown "Goodbye" screen
4) see if the alarm sounds at the scheduled time

Radio should wake up 2 minutes later (180 seconds before alarm time) but this bug prevents it from doing so.

I would suggest that someone with final hardware and a battery try the following to see if this bug would also prevent a Radio with a charged battery from waking a customer whose electricity went out overnight:

1) make sure the battery is fairly well charged
2) set an alarm for 30 minutes after the current time
3) unplug Radio from the wall
4) after 20 minutes, Radio should shut down to conserve battery
5) see if the alarm sounds at the scheduled time

If my guess is right, after 30 minutes Radio will remain off -- though it should turn on after about 27 minutes (180 seconds before the alarm) and make some kind of noise, even if MySB/SBS or the entire network is unavailable.

This is by design, currently.  If the user shuts down the Radio, the alarm should be disabled.

We can of course review this behavior if it seems incorrect.

Just a little extra info on the rationale about this design.

The user needs the ability to fully shutdown the device without it powering on for an alarm.

A use case is that you want to bring your squeezebox on vacation. You pack it in your carry on bag and in the security line, your radio powers up and starts playing the (in this case) fallback alarm.

While this may seem far-fetched, I bring this example up because that exact scenario has already happened to Tom last Fall. It is what precipitated the change.

This is an extreme example, but it's not unreasonable for a user to expect that a full manual shutdown from the front power button should result in it not auto-powering on for any circumstances.

IMO, fixing bug 14354 is an issue that needs fixing. With that fixed, there's nothing to do for this bug.

One last point-- I believe PB1 hardware is problematic for testing alarm, as there were changes to the hardware between PB1 and PVT2 that will effect the behavior of the wakeup microcontroller.

"IMO, fixing bug 14354 is an issue that needs fixing. With that fixed, there's
nothing to do for this bug."

I'm not so sure. Please run through my second use case -- make sure that line of code won't keep a Radio that's off due to a power failure from sounding its alarm.

"The user needs the ability to fully shutdown the device without it powering on
for an alarm."

Max already provided for that -- a customer can use the simple All Alarms control to turn off all alarms. 

It would also be nice to display more info on the Goodbye screen if there is an upcoming, active alarm. If you want Tom's logic to prevail, have the Goodbye screen say something like "Your upcoming alarms will NOT sound after Radio is turned off." If my suggestion prevails, Goodbye could say "Radio will wake up at 7:45 am on Tue, Mar 23 for your next alarm."

I don't agree that it's odd to have a route for fully turning off a device and not having it auto power-on. Let's fix the "too quick to fully turn off radio" bug and then really see if this is still a problem.

I also don't agree that All Alarms Off is the solution in this case, because you're arguing that a user needs to make an evaluation of configured alarms before they can truly turn their radio fully off. 

My opinion is that having "off, and I mean off until I decide to turn back on" is the correct design of long-hold on the power button. What needs fixing is the time required for long-hold.

I'll reopen this for further debate, but my own opinion is unchanged here. Fix 14354, this one should be WONTFIX

"you're arguing that a user needs to make an evaluation of configured alarms
before they can truly turn their radio fully off"

I'm arguing that --especially considering the comments I've read on the forum-- customers are unforgiving of an "alarm clock" failing to sound. I'm arguing that generally it's far better for a forgotten alarm to go off unexpectedly than for an alarm clock to remain silent if it technically could have awoken its owner. 

I don't think Tom's use case is a compelling argument for the current behavior. Most folks using Radio as an alarm clock will have it set to sound alarms at a given time on each day they need not to sleep late (workdays, church, etc.). If taking the Radio on vacation, presumably they'll plug Radio in and boot it up at their destination, and then they'll need to re-evaluate their alarms anyway -- how many vacationers want to wake up on the same schedule as at home? Why not re-evaluate the alarms before leaving home?

What do you think of my proposed changes to the Goodbye screen? They would require minor code changes (test if there's any upcoming enabled alarm), would not introduce any new UI/settings flow, and would make sure the user -- assuming he's paying attention to the screen when turning Radio off -- would know what to expect. In the Tom flow, you'd give some warning to folks who didn't realize that holding the off button longer would mean no alarm; in my flow, the vacationer would be reminded before packing his bag that Radio was scheduled to wake him up at 5:45 the next morning. 

Thanks.

Ah, on the 7.5.0 firmware, my patch does cause bug 14619 to recur *if* the SBS host is unreachable. In those cases, it does just what Tom described -- boots right back up after shutting down. Again, this is a PB1 build with not battery.

Hi Peter, I undertstand your arguments and they are good ones.  So far, we think that the current behavior is correct as Ben has noted.  There is a process in place where bugs that have previously been marked 'wontfix' are periodically reviewed.  If this bug gains support, we can certainly revisit it at some point.