Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 27 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 264
  1. #21
    Senior Member
    Join Date
    Dec 2009
    Posts
    137

    Radio alarms

    [cross-posted, with modifications, from the Radio forum. I will post here from now on with respect to the Radio alarm issue]


    I've spent a significant amount of time over the past few days analyzing, testing, and debugging the AlarmSnooze applet.

    I now have a significantly more stable applet that I'm running on a Radio with firmware version 7.4.1-r7915. I originally started with Ben's baseline version of AlarmSnoozeApplet.lua which was checked into SVN last Friday the 18th and made my modifications from there...

    There are still some minor problems remaining (most of which are systemic in nature and cannot, in my view, be fixed in a vacuum in the applet), but the core backup alarm functionality is much more deterministic now.

    I won't go into all the gory details unless people are interested (Ben??? ), but suffice it to say that it took many hours to understand the underlying system behavior because of the interaction between many separate layers of functionality in the context of alarms.

    This modified applet is also heavily instrumented, so the events that contribute to any alarm malfunctions will be clear and available in the system log for post-mortem analysis.

    The specific remaining problems that I'm cognizant of are as follows:

    1) When a new alarm notification is sent by the server (web interface) while an existing alarm is actually playing out at the radio (including during local snooze) then the new alarm will not have a local backup timer associated with it

    2) The backup alarm audio gain (volume) is fixed, and not configurable, as is the snooze time (9 minutes). Both of these characteristics are still as they were in the previous version of the applet.

    3) The backup alarm audio gain (volume) is sometimes moved during server reconnection events (when network conditions are dicey)


    The benefits, as seen in my testing:

    If you set a one shot or repeating alarm now, or even multiple one shot alarms (as long as you don't set any while the Radio is actually in the middle of having had one go off) I expect you'll be much better protected when/if your server connection goes away. The backup timer protection for the next upcoming alarm (though not necessarily those coming after it) has been greatly enhanced. Also greatly enhanced is the likelihood that the backup on-board alarm audio will actually play when the backup timer fires off.

    Ben, I won't be able to stay in sync with your applet changes subsequent to Friday the 18th, since your code and mine are now too divergent. Maybe you can have a look at what I've done and consider merging the changes you've made on yours subsequent to the 18th (if you think my applet is worthy as a good starting point). At least, my changes may give you the spark to look at functional areas you might not have considered yet. I read the list of changes you've made since the 18th, but it doesn't sound like you've had a chance to address all the functional problems that I have (I could be wrong, of course)...

    In the context of my modified applet (using your 18th version as a starting point), effort will/would still be needed to help clean up the remaining issues. The remaining issues appear to be systemic, as I mentioned, and relate to flow control/synchronizaton between different entities in the system (server, SqueezeOS, and applet communication). I have worked around some of the systemic problems by making changes in the applet, but there's only so much that can be done exclusively in AlarmSnooze itself...

    We can talk further about the outstanding problems that I believe remain if you are interested. I'm convinced that I now have a firm understanding of what the remaining problems are and can share suggestions toward resolving them (not to be presumptuous).

    I've also only tested my changes here in my environment, so it has had nothing near a real good shakeout yet. However, I really do think this modified applet can provide a good foundation for resolving the balance of alarm issues remaining.

    Ben, please advise how you'd like to proceed...

    Regards,
    Marc

    p.s. Below is a dump of information that I believe I've learned in terms of how alarms are synchronized between the Radio, SqueezeCenter, and MySB.com. The information may be useful for testing, understanding, and/or resolving alarm functionality problems:

    -------------------------------------------------------------------------------

    MySB.com:

    When 'mysqueezebox.com Integration' is not selected from the 'mysqueezebox' menu in SqueezeCenter (complete with MySB.com account credentials) then MySB.com has no alarm information at all (I'm not sure at this point if checking the setting actually does cause the provisioned alarms to be mirrored).

    Alarms are NOT uploaded from Radio when a new connection is formed to MySB.com. Instead, MySB seems to blindly request that all alarms be cleared!

    When an alarm is set up using MySB.com the alarm provision requests are sent blindly to the Radio after it is determined they will occur within 24 hours of the current time. There appears to be no check to determine whether the newly setup alarm falls before or after any existing alarm provision request previously sent to the Radio. *Note 1: So, my AlarmSnooze applet discards later requests when one that will occur sooner is pending (to prevent the cancelation of the existing RTC fallback timer, which would then leave the immediately pending alarm without fallback protection).

    When an alarm is set up directly at the Radio (using the dial) the information is stored locally at the Radio (and the alarm is armed if it falls earlier than the existing armed alarm OR if there are no alarms armed), but it is never uploaded to MySB.com. MySB.com only shows and maintains alarms that have been set up there using the players->alarms webpage.


    SqueezeCenter:

    An later alarm time is never sent by the server if an earlier one is already enabled. SqueezeCenter is obviously comparing the alarm settings (for those that are currently enabled) and will only send the actual next chronologically appropriate alarm initiation request to the Radio.

    When a new connection is established between the Radio and SqueezeCenter the alarm information existing on the Radio is uploaded and properly reflected at SqueezeCenter. Synchronization appears to be automatic.


    Radio UI direct:

    When an earlier alarm (with commensurate RTC fallback timer armed) is deleted, the next chronologically appropriate enabled alarm immediately causes an alarm initiation request to be sent to the AlarmSnooze applet. *Note 2: Out of paranoia for the different behavior exhibited by MySB (where later alarms are sent unconditionally), my applet then disregards it because the previous alarm was not explicitly canceled first.

    *Note3: always navigate back to the 'Settings' menu and then select 'Alarm Clock' again to see any updated alarm settings at the Radio. The screens are not dynamically refreshed when settings are changed so this is the way to be sure you are seeing the actual current alarm settings.


    Note1 and Note2 reflect mutually exclusive behaviors where MySB.com and SqueezeCenter appear to operate in separate manners when provisioning an alarm. The AlarmSnooze applet could treat the two situations differently depending upon which server the Radio is currently connected to, however the boundary conditions that will likely pop up in the context of switching server connections could still cause problems.
    Last edited by Marc; 2009-12-23 at 16:35. Reason: spelling/grammar

  2. #22
    Senior Member
    Join Date
    Dec 2009
    Posts
    137

    Radio alarms

    Quote Originally Posted by bklaas View Post
    summary of changes since I've been able to refocus on the radio alarm:
    1. Fallback timer runs at all times, not just when squeezeplay receives a serverDisconnect notification. This may help solve some reliability issues being seen, though admittedly that's somewhat of a guess and needs some more eyes/ears to see how it's doing now.
    2. "Turn Alarm Off" stops alarm but not audio
    3. Alarm notification window hides itself after 59 seconds
    4. Alarm volume slider UI issue fixed (server side fix)
    5. When radio is controlling another player and local radio alarm fires, more intelligently change the controlled player back to the radio
    6. Remove alarm notification window when power button is hit
    7. Always hide existing alarm window when alarmState notification changes

    These changes are being made in 7.4/trunk but are also being pulled up to the 7.5/trunk branch.

    cheers,
    #!/ben

    Hi Ben,

    I diffed the changes you've made since the revision I started with from last Friday the 18th and had a few comments.

    Honestly, I'm a bit confused by the seeming focus on windows and user-visible screen feedback when the underlying core alarm functionality is broken.

    It doesn't look like the focus is actually on fixing the Radio alarm operation so it's rock solid as much as nipping at the periphery of alarm presentation. I don't mean any offense, but I've taken a different road here with the changes I've made. I've focused on only the core alarm issues which frequently end up causing alarms to be entirely missed, alarm audio to mysteriously stop playing, etc...

    I've made a variety of logic changes that go to the heart of the alarm instability issues that I hope you'll have a look at. I've also added detailed instrumentation that should readily provide answers when and if instability continues to manifest in a given user's environment. The changes are really too wide in scope to address in detail here, but you'll get a good idea by just diffing against your Friday 12/18 version that I started with as a baseline...

    Where you listed the changes you've made since refocusing on alarms, I think it's worth mentioning...

    1. Having the RTC running for fallback in all cases definitely makes sense, however major holes remain in the logic from the 12/18 version (which was the last time RTC functionality was touched). I've addressed those significant holes in my applet changes. This was the primary focus of what I chased and changed (although it does not constitute the entirety of my changes). If this functionality isn't made the primary focus of applet changes prior to beta testing (or other distribution of the new applet) then I don't think Radio adopters who are upset about the widespread failure of alarms will be placated. I think they'll only be further peeved, actually. It doesn't matter so much how the user presentation shakes out if, at the same time, the alarm(s) can't be trusted to fire properly. Honestly, I didn't guess in the context of my changes. I hunted down what was happening, ascertained why the behavior was occurring, and then fixed the issues (where possible -since in some cases the ultimate fix can't be made due to systemic Radio<-->server communication issues)...

    I've attached my modified AlarmSnoozeApplet so you can have a look (added .txt so it would upload). Keep in mind there is still a specific piece of logic that needs to be finalized (it's not completely done in terms of RTC fallback hardening). I find it very difficult to wrap up this issue because MySB.com and SqueezeCenter both operate differently in terms of the way they send provisioned alarms to the Radio. See my previous post on alarm-related synchronization/flow control issues for detailed information...

    Regards,
    Marc
    Last edited by Marc; 2010-01-02 at 22:19. Reason: removed attached applet to avoid multiple version clutter

  3. #23
    Senior Member bluegaspode's Avatar
    Join Date
    Jul 2009
    Location
    Berlin, Germany
    Posts
    3,221
    Marc,

    I tried to review your code but your changes are too much
    What I read from your changes though is, that you built and testet a lot of scenarios (most of which presumly fail before your changes) and also handled some corner cases (like a reconnecting server while the alarm is playing).

    As the whole alarm thing is pretty complicated (and I guess in future times there will be changes again) I think its very important to document all scenarios the alarm has been hardened against now (in the hope that Logitech QA will write them down in their own test scenarios).

    I'll go and test your changes against the failure scenarios I put up (http://bugs.slimdevices.com/show_bug.cgi?id=14870#c23) ... maybe I won't finish before the grandparents arive *G* ... so merry christmas and thanks for taking your time
    Did you know: SqueezePlayer will stream all your music to your Android device. Take your music everywhere!
    Remote Control + Streaming to your iPad? Squeezebox + iPad = SqueezePad
    Want to see a Weather Forecast on your Radio/Touch/Controller ? => why not try my Weather Forecast Applet
    Want to use the Headphones with your Controller ? => why not try my Headphone Switcher Applet

  4. #24
    Senior Member
    Join Date
    Dec 2009
    Posts
    137
    Bluegaspode,

    You're right about what and how I tested, in general. Server connection/disconnection is the most interesting (and variable) part of the equation. I was surprised at how the reconnection logic behaved and expect the Squeeze developers may be changing the behavior (purposefully or not) going forward...

    Keep in mind that there are still a couple of things that need minimal tweaking in my modified applet. For example, you'll see there's a log:error call in notify_playerAlarmState that I was just using to get a call stack trace during certain event deliveries (so I could tell the flow of the message upward through SqueezeOS)...

    Also, it's very important to be cognizant of which server you are testing with. MySB and SqueezeCenter both behave very differently (today, at least) in terms of how they communicate provisioned alarm information to the Radio. The applet code I attached will not properly account for alarms provisioned directly at the Radio if there is already a previous alarm enabled. This is because of the different alarm provisioning behaviors that must be accounted for, depending upon which entity (MySB, SqueezeCenter, or Radio direct) is used to provision alarms.

    I'd suggest focusing on one particular provisioning model at the outset; for example, always provision with MySB to begin with... at least for testing purposes, that is...

    The system log should have detailed information on what has transpired, so getting familiar with the output there should help greatly when analyzing unexpected behaviors.

    When the local fallback alarm fires, don't be surprised if sometimes the audio briefly stops and then restarts. I had to do that as a workaround for some of the systemic problems that I've mentioned.

    Behavior within the applet really can't be properly finalized without the resolution of systemic behavioral anomalies in the alarm provisioning path. That's why I was reticent to just release my modifications immediately.

    Your testing can only help, of course...

    I wish Logitech would pay serious attention to the systemic issues I discussed in a previous post. The bottom line is that the differences in alarm provisioning behavior between MySB, SqueezeCenter, and Radio contribute significantly to the ongoing alarm problems. The proper way to fix these issues is to normalize the disparate behaviors so they don't have to be distinctly accounted for within the applet (in some cases this accounting for differences would/will be VERY hard to get right due to boundary conditions). IF I COULD BOLD THIS PARAGRAPH THEN I WOULD!


    Thanks for the time you've put in on other applet areas, by the way. And enjoy the grandparents' visit! Maybe you should set an alarm for dessert time?

    Marc

    p.s. I see now (after reviewing the bug you pointed at) that you are wrestling also with multiple pipelined alarms. I haven't focused on any of those scenarios yet, so be forewarned. First it made sense to get a single alarm working properly. The combination of IP changing (meaning lost connection to MySB), starting and/or stopping SqueezeCenter, Radio automatic reconnection behavior, and disparate behavior in how provisioned alarms are handled by the different entities makes for a WORLD of variability in the situation where multiple alarms are being dealt with. Indeed, there is plenty of variability, due to the factors I listed, when using just one alarm...
    Last edited by Marc; 2009-12-24 at 08:03. Reason: added p.s. about multiple alarms

  5. #25
    Ne'er-do-well, Vagabond bklaas's Avatar
    Join Date
    Apr 2005
    Location
    Minneapolis, MN
    Posts
    2,033
    hi Marc-

    Thanks for attaching your work, I will review what you did.

    FYI, I'm on vacation now and not returning to work until 4 January (as is the majority of the Logitech Squeezebox team). Please don't take my lack of response over the next week and a half as disinterest in this topic.

    I'm not going to go into great detail with the many points you've brought up right now (after all, I am on vacation), but one thing I want to point out is that there should not be any functional difference in the mechanism of a mysb.com alarm and a squeezecenter alarm. I recognize you are seeing differences, but there should not be. The server alarm code is fully shared between them (Slim::Utils::Alarm), and this code also serves legacy players (Squeezebox Boom, Squeezebox Classic, etc.).

    Also, the customer's broadband IP address changing should not kill the mysb.com connection. There is a separate bug open against the mysb.com connection problems being seen, mostly be people in Europe. If that extremely high priority bug gets fixed, that should go a long way to dealing with alarm reliability issues.

    cheers,
    #!/ben
    Former Logitech Developer: Squeezeplay/SqueezeOS/SqueezeboxController/SqueezeCenter
    Community Developer: Nokia770Skin (r.i.p.)

    http://www.last.fm/user/bklaas/
    KHAAAN!...BUNNIES!

  6. #26
    Senior Member
    Join Date
    Dec 2009
    Posts
    137
    I hear what you're saying, Ben, about how the server behavior shouldn't be different. My testing has revealed otherwise in practice, though...

    I'm sure you're right about the underlying disconnection issue being closely associated with the Radio alarm problems. There also seems to be a related initialization/reset of some kind being done on the local player and/or underlying audio subsystem when reconnection occurs. So, the audio output state is being modified under the covers due to the (re)connection sequence and sometimes stopping (or otherwise screwing up; for example, by changing the volume level) existing alarm audio playout or preventing upcoming alarm audio playout. That's exactly why I added the 'sledgehammer' logic to wrestle back control of the local player/audio output state after (re)connection events. So, I concur that correcting the connectivity issue will surely mitigate the frequency of malfunctioning alarms. That being said, the internet will be the internet... so, connections to MySB *will* still be lost periodically and the logic problems remaining in alarm functionality, while certainly being seen far less often, will remain to sporadically bite Radio owners.

    In the short term I'm almost tempted to suggest that Radio owners who want the best alarm stability (or who want to test system updates to see if they work better) stop using MySB.com to provision alarms. If this were the general consensus then the testing of changes and ultimately the hardening of alarm stability would happen far more smoothly and far more quickly.

    As a matter of fact, I may go back to my changed AlarmSnooze applet and tweak it in the appropriate ways based upon the presumption that MySB.com provisioning is NOT to occur. Hmmmm... Frankly (and I know this is a marketing decision that far transcends R&D there at Logitech), I'm far from sold on the usefulness of provisioning alarms from MySB.com. The local interface on the Radio for provisioning alarms is quite good, in my opinion (kudos on that, by the way) and only slightly more tedious (if at all) than setting up an alarm on a typical clock radio. So, maybe there isn't actually a need to provide alarm provisioning from MySB.com.

    Thanks for your attention to the issue, and to this forum, Ben. And Happy Holidays!

    Marc

  7. #27
    Ne'er-do-well, Vagabond bklaas's Avatar
    Join Date
    Apr 2005
    Location
    Minneapolis, MN
    Posts
    2,033
    for clarity, when you say "provisioning alarms on mysb.com", you are saying that you are setting up the alarms *via a web browser pointed to mysb.com*. Is that correct? If so, I've been misunderstanding you and this should be definitely investigated. My personal opinion is that we should strip the mysb.com interface of these functions, which are so much better served via the device. However, that is not my decision to make.

    The source of my confusion is that if you setup an alarm *via the squeezebox radio* while connected to mysb.com, I consider this to be a mysb.com provisioned alarm. That is, when you configure an alarm on the SBRadio in this setup, you *are* setting up a mysb.com server-side alarm.

    I'm going to take a small amount of issue about what you said about underlying logic problems in the AlarmSnoozeApplet. IMO the logic of the applet is pretty straightforward and not fundamentally flawed. I fully acknowledge there are alarm reliability issues being seen, but the core functionality of the applet is solid. The key thing to investigate is why mysb.com connections are unreliable and intermittent, and fix those.

    Now I really am going on vacation

    cheers,
    #!/ben
    Former Logitech Developer: Squeezeplay/SqueezeOS/SqueezeboxController/SqueezeCenter
    Community Developer: Nokia770Skin (r.i.p.)

    http://www.last.fm/user/bklaas/
    KHAAAN!...BUNNIES!

  8. #28
    Senior Member
    Join Date
    Dec 2009
    Posts
    137
    Quote Originally Posted by bklaas View Post
    for clarity, when you say "provisioning alarms on mysb.com", you are saying that you are setting up the alarms *via a web browser pointed to mysb.com*. Is that correct? If so, I've been misunderstanding you and this should be definitely investigated. My personal opinion is that we should strip the mysb.com interface of these functions, which are so much better served via the device. However, that is not my decision to make.
    Yes, when I say provisioning alarms on MySB.com I indeed mean setting up the alarms via a web browser pointed to MySB.com (with the Radio currently connected to MySB.com). Correct. It sounds like we're in absolute agreement about stripping the MySB.com interface of this function. It's no surprise that it's not your decision, though. It's unfortunate that a corporate position like this is taken without involving engineering for discussion (if that's the case), but I've seen similar scenarios in my embedded career as well... {sigh} Perhaps the most unfortunate part is that even if and when the MySB.com alarm provisioning interface could be normalized to behave like the other methods used to set up alarms (SqueezeCenter and Radio-direct), I still think it will not be trivial to properly implement the actual synchronization of provisioned (set up) alarm information between all the different entities. The boundary cases involved (when switching from one server to the other, for example) are going to continue to cause trouble in my estimation...

    Going forward (for now), I am definitely going to focus on the alarm issues from the perspective that the MySB.com webpage will not be used to set up alarms. There are just too many variables between the connection/disconnection issues and different provisioning behavior. The strong recommendation should be that those using MySB.com (as opposed to SqueezeCenter) set up their alarms directly at the Radio (which is very easy to do, as I mentioned).

    Quote Originally Posted by bklaas View Post
    The source of my confusion is that if you setup an alarm *via the squeezebox radio* while connected to mysb.com, I consider this to be a mysb.com provisioned alarm. That is, when you configure an alarm on the SBRadio in this setup, you *are* setting up a mysb.com server-side alarm.
    I see what you mean. Now I understand where the confusion came from. Whenever I've talked about MySB provisioned alarms I have been referring to the use of the MySB.com webpage to do so. When referring to the use of the Radio dial/buttons themselves I've written something like 'Radio-direct' or 'Radio provisioned'. Maybe when you get a chance to go back and re-read what I wrote about the different behaviors it will now make more sense.


    Quote Originally Posted by bklaas View Post
    I'm going to take a small amount of issue about what you said about underlying logic problems in the AlarmSnoozeApplet. IMO the logic of the applet is pretty straightforward and not fundamentally flawed. I fully acknowledge there are alarm reliability issues being seen, but the core functionality of the applet is solid. The key thing to investigate is why mysb.com connections are unreliable and intermittent, and fix those.

    I hear what you're saying, and honestly didn't mean any offense. As I said before, I wholly agree about the connection problems being at the heart of the alarm stability problems. Again though, even if the MySB connection issues are perfectly resolved to be as reliable as possible, there will still be outstanding problems to address (since they exist today): These include the problems associated with Radio<-->server automatic reconnection and commensurate reinitialization of [certain] Radio audio subsystem settings when reconnection occurs. No matter how solid the MySB.com connections are made, Radios will always be in some danger of losing their connection to MySB.com due to the nature of internet connectivity. When these connection losses occur they will be outside the control of the the Logitech development team and it will be incumbent on the Radio/MySB.com software to resynchronize appropriately without torquing the Radio's ability to fire a stable alarm. The two issues I referenced above must still be resolved (alongside the resolution of the changing-IP-causing-MySB-disconnection issues) before stable alarm functionality is achievable... It's true that most of the changes I made in the AlarmSnooze applet relate to defensive measures needed to work around the underlying infrastructure issues I've repeatedly mentioned.

    There *is* another issue, though, that we haven't discussed much yet. I figured there were enough high priority items being discussed already that needed to be addressed. It doesn't make too much sense to further muddy the waters before the other high priority items can be cleaned up to the degree that a single alarm works reliably and consistently. This separate issue relates to having multiple alarms enabled at the same time. In my investigation I have not seen the code in place at the Radio (essentially AlarmSnoozeApplet.lua and Player.lua) to properly handle this scenario. I haven't focused on it, as I mentioned above, since single alarms must be made stable first... However, I am convinced that additional flow control and/or other AlarmSnooze changes are necessary to make this case work right...


    Quote Originally Posted by bklaas View Post
    Now I really am going on vacation

    cheers,
    #!/ben

    Enjoy! You deserve it! (though I bet you can't resist having a peek back here once or twice...)

    Marc
    Last edited by Marc; 2009-12-25 at 12:45. Reason: spelling

  9. #29
    Senior Member
    Join Date
    Dec 2009
    Posts
    137

    Slightly modified AlarmSnoozeApplet.lua for testing

    This attached version is only slightly modified from the previous one. A call stack trace (log:error call) line has been removed from notify_playerAlarmState(...) and an additional sledgehammer(...) call has been added to notify_playerConnected(...)

    I removed the call stack trace just to reduce some log clutter. The additional sledgehammer call was added because I saw a case where notify_playerConnected was the last routine notification call made by SqueezeOS immediately prior to an audio playout malfunction during testing. In this case the audio gain (volume) was turned way down to almost nothing by some logic under the covers that I feel confident is related to the automatic player initialization sequence associated with a newly formed connection.

    If you are going to test out the changes I've made then please use the applet attached to this post (until there is cause for a new one, that is). I will go back and edit the post associated with the previous version I attached (that was really just for Ben and Bluegaspode to review, to get the ball rolling).

    Again, don't be surprised if the backup alarm case and a bouncing connection results in the audio output stopping for a short period of time before resuming. This is the scenario where some logic in the Radio, not in the AlarmSnooze applet, is (re)setting some of the local player and/or audio subsystem settings after a newly formed connection; when the commensurate notification (there are many different notification types I've seen that can occur alongside this problem) callback arrives at the AlarmSnooze applet I attempt to wrestle back the local player and audio subsystem asynchronously - with a short delay - so that hopefully whatever is automagically mucking with the player/audio settings will be finished by the time AlarmSnooze tries to restart its own fallback alarm audio playout.

    Another thing to be aware of: The snooze timer associated with the RTC fallback alarm is hardwired at 1 minute for testing convenience.

    I am no longer ever configuring/provisioning/setting-up alarms using the MySB.com webpage. I don't trust it and using it throws a nasty monkey wrench into the process of analyzing alarm behavior. When I test with the Radio connected to MySB.com I *always* configure alarms using the Radio dial/buttons directly. I strongly suggest that others do the same, since there is just too much variability when configuring alarms via the MySB.com webpage for now...

    Marc
    Last edited by Marc; 2010-01-02 at 22:19. Reason: removed attached applet to avoid multiple version clutter

  10. #30
    Quote Originally Posted by Marc View Post
    As I said before, I wholly agree about the connection problems being at the heart of the alarm stability problems. Again though, even if the MySB connection issues are perfectly resolved to be as reliable as possible, there will still be outstanding problems to address (since they exist today): These include the problems associated with Radio<-->server automatic reconnection and commensurate reinitialization of [certain] Radio audio subsystem settings when reconnection occurs. No matter how solid the MySB.com connections are made, Radios will always be in some danger of losing their connection to MySB.com due to the nature of internet connectivity. When these connection losses occur they will be outside the control of the the Logitech development team and it will be incumbent on the Radio/MySB.com software to resynchronize appropriately without torquing the Radio's ability to fire a stable alarm. The two issues I referenced above must still be resolved (alongside the resolution of the changing-IP-causing-MySB-disconnection issues) before stable alarm functionality is achievable... It's true that most of the changes I made in the AlarmSnooze applet relate to defensive measures needed to work around the underlying infrastructure issues I've repeatedly mentioned.
    I've only used a Squeezebox for an alarm once, exactly once, so I'm not the best to comment on this, but defensive programming seems very prudent here. Squeezeboxes should have reliable alarm functions even if the entire Internet is crumbling under the mother of all DDoS attacks. No offense, Ben, but I think a design that is based on the presumption of a stable connection to a MySB or even SBS server is a poor design for an alarm clock. I wouldn't want to miss my alarm on Monday morning just because my neighbor installs some gear on Sunday night that kills my WLAN.

    Reliance on the server would actually be a bigger problem with Radio/SqueezePlay than with Boom and the original IP3K "dumb" clients. With IP3K gear, users get immediate visual indication when a server connection is lost. With Radio/SqueezePlay --in my experience-- a user only knows that a connection is down if the user tries to interact with server-dependent menus. Otherwise the Squeezebox just displays the same old Idle/Off screensaver. With IP3K at least you'd have a hint if the network or server died before you fell asleep.

    Furthermore, I expect Radio should be significantly better than Boom. Boom has a 24-hour clock and a limited CPU & development environment. I understand how my Monday alarm would fail if my SBS box crashed on Saturday and I didn't fix it. But Radio should be far, far smarter. It should have local info about much more than just the next alarm scheduled for < 1 day out.

    I may well be misunderstanding the architecture -- at this point I think you two and Max probably understand how this works far better than I do. So I apologize for the details I'm getting wrong. I just want to say that I think the code should be defensive enough to work well for alarms that have already been set/requested even if both SBS and MySB are very unreliable.

    Happy holidays,

    Peter
    owner of the stuff at https://tuxreborn.netlify.com/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •