Philip Meyer;548506 Wrote:
It's getting painfully obvious that it gets too complex to reliably
include anything that's dependent on the network or a server when
triggering the alarm in the Radio.
I don't know why that should be the case - my SB3 alarm works reliably,
and that should be less
bluegaspode;548509 Wrote:
I miss:
- (for the start) fadein of the mp3 .
Agreed, that should definitely be included
bluegaspode;548509 Wrote:
- (for the second release) I'm a Radio fan. I didn't want to wakeup to
the same tune every day. Which means you had to support starting a
Philip Meyer;548506 Wrote:
It's getting painfully obvious that it gets too complex to reliably
include anything that's dependent on the network or a server when
triggering the alarm in the Radio.
I don't know why that should be the case - my SB3 alarm works reliably,
and that should be less
erland;548517 Wrote:
I just know that my Radio wakes me up with normal music every morning
and almost gives me a heart attack a number of minutes later when my
nice music is replaces by the fallback alarm. By looking in the logs it
seems like it's caused by short temporary network problem. I
Great idea erland. Getting a simple function back to... simple.
Couple of suggestions:
- small selection of basic Alarm sounds to choose from (bells, chimes,
siren, voice recording of my mother-in-law)
- pressing Play dismisses the Alarm, plays the last item played
- pressing a Preset
To your feature list I'd add the ability to set a different alarm for
each day of the week (I disagree with bluegaspode on that, obviously).
I don't think you need the ability to set N arbitrary alarms, but I do
think it would be nice to try to accommodate users who don't wake up
the same time
erland;548517 Wrote:
I'm not sure I want to add things like this, it will make it too
complex. Sending WOL to the server should be ok, but just to make sure
it's alive when you turn off the alarm and selects to continue playing
your radio favorite/preset instead.
What is the lead-time on
Don't forget that there would still be prospective problems even with a
totally localized alarm application. Without the proper
synchronization between local (Radio based) apps and server requests
the playout subsystem may well end up fought over (which is what
sometimes happens today with the
It's getting painfully obvious that it gets too complex to reliably
include anything that's dependent on the network or a server when
triggering the alarm in the Radio. I'm sure it's possible to do but
probably not within a reasonable time/cost with the limited number of
development resources
But if the user is instructed to simply don't configure any alarms on
the server(s).
If you do a completely independent simple alarm applet
The only conflict I see is that it tries to fire to many alarms your
proposed applet and the built in alarm (if configured).
Giving you not only a heart
10 matches
Mail list logo