>Alarm timeout = 0 for me still is an 'invalid' setting because its
>meaning is ambigious - so I wouldn't put ANY trust in it to keeps its
>behaviour between software versions.
>
I agree; at first glance the Alarm Timeout = 0 setting in the Web UI > Settings
> Player > Alarm Clock is ambiguous.
However, if you read the tooltip for the setting in the web UI, it says:
"This setting allows you to choose how long alarms will play
for before they stop automatically. If set to 0, alarms will
continue playing until they are stopped manually."
i.e, it should start the alarm playback and keep playing until manually stopped.
>So the only (proper) solution is to start an enhancement request to
>remove timeout=0 and create a new unambigious option.
>
I think the setting is okay as it is, timeout=0 meaning play the alarm with no
timeout. This applies to any type of player. Removing/replacing it could
break existing classic players.
The display of the popup modal dialog is specific to Radio (and Touch?); there
should be a separate setting to define how the alarm interface works dependent
on player type. This could be handled generically, as mentioned in other
threads, by having an Alarm Display ("Screensaver") mode, so the user could
pick an appropriate display mode per-player. eg. either "Popup Dialog"
(perhaps the default), various clock displays, Now Playing screen, etc.
If Alarm Timeout = 0, the player won't be in alarm mode, and therefore the
"When Playing" screensaver would always be displayed.
_______________________________________________
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
