bluegaspode;507010 Wrote: > Anyway: I think your points are valid and I would support them (though I > don't know how difficult they are to implement): Thanks. I would like to raise these on the bug/enhancement list then. Presumably will have to create an account to do that.
bluegaspode;507010 Wrote: > - when snoozing or stopping radio should revert to the state it was > before Sounds good to me too. Currently it's a pain. bluegaspode;507010 Wrote: > - there should be some indication when snoozed (at least I could think > of a small female voice hissing 'SNOOZE ACTIVATED' the moment you enter > Snooze mode) *G* Wasn't sure if you were joking about the voice notification, but actually quite like the idea of some audible notification when you hit snooze. It has the added advantage that you don't need a new UI state (ie snoozing). It gives you the peace of mind that the server has registered the new alarm. Makes me want to test that the fallback alarm is updated when you initiate a snooze. So that if the server goes down mid-snooze, that the radio reverts to the fallback. I expect so, but wouldn't hurt to check. This architecture certainly adds plenty of complexity and room for error. I did discover (to my pleasant surpsise) that if you delete the original alarm whilst in mid-snooze, the server does still fire the snooze. I know this isn't going to change, but can't help thinking that implementing alarms from the server side (as opposed to the client waking up and initiating the audio stream) makes life far more complicated than it ought to be - particularly when you add the extra confusion of switching between a local server AND mySqueezebox.com. Rob -- squishy ------------------------------------------------------------------------ squishy's Profile: http://forums.slimdevices.com/member.php?userid=35390 View this thread: http://forums.slimdevices.com/showthread.php?t=73211 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
