Ok, I've been testing all day directly on my Radio, which has firmware version 7.4.1-r7915 installed.
I tested with both the AlarmSnooze applet that was packaged with 7.4.1 and then afterward with the newest available AlarmSnooze applet which is packaged with Squeezeplay (I downloaded Squeezeplay this morning). The AlarmSnooze applet packaged with Squeezeplay is clearly the new one which has been changed to invariably arm a local RTC timer even when the Radio is still connected to the server. I have a file of applicable log output from AlarmSnooze on debug level that I can post if there is interest (I may also post it to bugzilla if I'm able and it makes sense), but the bottom line is this: The 7.4.1 included applet just doesn't have enough synchronization in the context of the local RTC timer and server connection state to stay sane. Even when the fallback timer/alarm does work, the logic is not clean. There is a high likelihood that this applet will start an extraneous (additional) local timer after the original local timer has been setup and taken. Then when that additional (extraneous) timer is stopped (whether due to a server connection event or otherwise) the backup alarm that has just started playing (or which may not yet even have started playing) can be stopped. The newer applet is much more stable since the conditional logic to determine whether or not to start a local timer has been essentially eliminated. There are still holes, from my perspective, in the logic, however it is much better than it was before. I don't see any extraneous timers being armed with this later applet, and it appears to run much more deterministically than the earlier one. I did encounter a problem, however, with this newer applet and still had the currently playing backup alarm stop playing by itself due to a logic problem in the code. The applet blindly stops the locally playing alarm file when/if there is a server connection event reported. At this point another stream was briefly played before stopping. The interlocks for asynchronous events (server connection and disconnection events seem to be reported asynchronously via callback from an OS context) needs to be tighter. For those desiring more stable alarms, I do highly recommend grabbing the newer applet since it is clearly more stable. Don't be surprised if there are still some problems, though. Particularly if the server connection is bouncing to some degree. I'm going to continue to look at the newer applet (though I've never seen Lua before, it doesn't look particularly complex) and attempt to harden it further... -- Marc ------------------------------------------------------------------------ Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72393 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
