Re: [SlimDevices: Radio] Weird alarm behaviour
TopGeek;688585 Wrote: That's a real shame, Marc but, with 3-4 alarm malfunctions in only just over one month of experience, it certainly seems that your summation of the situation is correct - i.e. this is not a reliable alarm clock. Mind you, it also seems to be a fairly unreliable Internet radio. I've already had the experience of one of my favourite stations disappearing for more than a week while others were telling me they could still get it. I get frequent dropouts of up to 30 seconds on radio signals, while there is no wifi or Internet interruption. It only has a mono speaker, although it does have a stereo decoder so I can at least appreciate stereo sound in my earphones. The impression I get is that this is a Beta product that should not yet be on sale to the public. Your impressions are largely accurate. I haven't got experience with recent revisions of Radio firmware so I can't comment directly there. You see, I still run firmware version 7.4.2, along with my own custom modifications to the Radio alarm code, and will not update the firmware on my Radios again... ever. 7.4.2 is indeed adequately stable for my purposes. While there are certain things that don't always work right, the failure modes are usually deterministic enough so that working around them and/or taking corrective action when these errors occur has become second nature for me. When you keep upgrading to new firmware versions you leave yourself open to whatever new bugs are introduced (obviously). That's true of all embedded systems, of course, but in the Radio's case the underlying software architecture implementation is not one that is conducive to facilitating new releases that are stable. 7.4.2 was the current version back when I originally modified the alarm code to be as stable as was possible. I explained directly to Logitech development at that time, and in detail, that the Radio software architecture did not incorporate the proper client/server model to allow infrastructure stability over the long haul (or the short one). They didn't listen (likely due to shortsightedness, resource constraints, the desire to heavily leverage the existing code base from the time that Squeezebox devices were far less intelligent, or for other reasons - but who from afar can be certain why an engineering organization actually does what it does). I knew then that alarms would likely never be particularly stable. Further, they would likely never be as stable as I had already made them with my modifications. I state this not to be presumptuous, but instead because it was clear to me then that even after I had shared all of my code and thoughts with them as to why and how the infrastructure was inadequate they elected to take the band-aid approach. That's when I 'cut bait' and decided to stick with 7.4.2 and my custom alarm mods instead of upgrading to the next release... I further opined, after extensive investigation - and modification - of the Radio firmware, that much other Radio functionality was also at risk of stability issues due to improper architecture. It's all here in the forum archives, I believe, if you're interested in the gory details. Practically speaking, the point is that once you find a version of Radio firmware that suits your purposes it may make sense to hard stop there and never upgrade again. New releases don't necessarily mean more stable operation when device software architecture/infrastructure is suspect. In the case of this device it is as likely that a new release means newly introduced instabilities in areas that seemed previously stable and deterministic in operation. If you investigate and understand the history of the Radio's software then you'll likely be convinced to spare yourself the time you would have spent applying firmware upgrades, writing forum posts, and chasing down Radio errors and instead apply that time toward other more constructive pursuits. I pop into the forum rarely now, and really only for entertainment purposes. It was not always that way, but there's only so much that can be done... In the case of the Radio, if you are a tinkerer who enjoys chasing and isolating new problems then it's the perfect platform to mess around with. If, however, you are only interested as a consumer in a stable/functional device to use for streaming and alarms you are barking up the wrong tree. With this post I would hope to save some Radio owners (who don't yet necessarily know any better) from the misguided notion that you'll 'soon' see stable firmware. Find a version that works for your purposes and in the context of the particular functionality that you desire from the device, and then stand pat... Regards, Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=93038
Re: [SlimDevices: Radio] Weird alarm behaviour
TopGeek;687449 Wrote: The firmware is the latest. I regularly ask for an update. It probably is a server fault and I am using mysqueezebox.com, not my own PC. I'm not clear why you suggest a different time setting and I do not want to use the radio station as an alarm. I deliberately selected a gentle cascade sound fading in, as my wife sleeps longer than me and I respond to the alarm well before it wakes her. Can't seem to sleep here (while admittedly unrelated to the Radio alarm - haha), so I'm taking a rare gander at the forum... Honestly, if your wife is getting upset and you risk her wrath every time the alarm does something obnoxious then my advice is to stop using the Radio alarm and start relying exclusively on another alarm device. I don't advise this glibly... The Radio is a fine streaming device, but it is not an adequate or particularly reliable alarm clock (with the Logitech provided code base). Either trust me on this or do some forum searching for the historical discussions regarding alarms that I've engaged in with Logitech development. It will not get better with firmware updates in reality, as the Radio alarm architecture is not conducive to stability. Even if a future firmware version appears to 'get it right', you will always run the genuine risk of a future firmware update regression that causes annoying alarm behavior anew. In your particular case, since you don't care about streaming music or internet radio as the alarm audio source, there is one additional option... you could modify the code to use a truly local (Radio resident) audio sample of your choice and remove the server entirely from the equation. Then the alarm behavior would be maximally stable for your purposes. You would, however, be stuck in having to reapply the code changes after every Radio firmware update pushed down from Logitech if you did this... Frankly, if your domestic situation is at any risk then you'll do well to posthaste abandon the notion that the Radio provided alarm functionality will never again stir your other half with a jolt. Cut your losses and enjoy the Radio for its streaming while you fall back to another alarm device to keep the peace in the bedroom... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=93038 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Questions Regarding Alarm
Simon300;600896 Wrote: Ironic when you'd have thought a bedside radio was a key target market (though it is a bit pricey for just that). It's a real shame that Logitech haven't put the effort in - some of the bugs would probably only take a junior developer to fix. 0xdeadbeef;601063 Wrote: There are indeed lots of smaller issues that should be fixable within hours if not minutes which leaves the question why this didn't happen yet. Even if there was only one underpaid Chinese developer working on this, as this is the case for the typical media player, it's kinda unexplainable that really close to nothing was improved in more than one year. The again, I'm still convinced that the whole alarm design is so completely ill designed from the core that there is no easy fix anymore. I guess too much money was invested in the MYSB server infrastructure instead of putting a little thought in a sensible system design. And now it's probably too late for the responsibles to admit their failure. Just catching up and checking in after quite a long hiatus... To underscore the comments above (and correct the notion that a junior developer - of any nationality - could fix the alarm problems), the real problem with alarms is indeed the architecture. I discussed this directly and repeatedly back when I fixed them as best as possible in light of the constraints presented by the alarm architecture (and certain underlying foundational architectural constraints relied upon by alarm functionality). The continuing problems won't be fixed by any junior developer, nor any senior one unless the architecture is fixed first. Bluegaspode's continued work to address/resolve specific users' alarm failure/malfunction cases is laudable (ahh, your patience continues to amaze, Stefan :) ) - but the grander issue of why those problems are not innately addressed by default in the alarm subsystem will never be resolved. Which is precisely why I am still running 7.4.2 from back when I originally made alarms usable, and am no longer tinkering with further fixes... Marc p.s. I absolutely love the SB Radio as a streaming music player. For use as a bedside alarm clock, however, see my opinions/posts from long back - since none of the realities/views expressed there have changed. -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=83998 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Battery doesn't appear to be charging
szalik;549846 Wrote: I think you need firmware 7.5.x to properly use (charge) the battery. Thanks for the response. Not sure that's the case, though. I unplugged the Radio (largely since I was afraid the battery might be entirely drained otherwise) for half a day and then plugged it back in. It powered up (I did not upgrade the firmware and am running the same version I listed earlier) and then started charging the battery. Everything is working fine now... Weird, but not a shock frankly... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=79039 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
[SlimDevices: Radio] Battery doesn't appear to be charging
Just received my battery and installed it according to directions. I'm running firmware version 7.4.2 (r8423) and the battery icon shows up on the screen, however, it is not blinking or otherwise animated. Advanced-Diagnostics-Power shows as follows: MSP version: 1313 Battery voltage: 12.787 V Battery vmon1: 3.711 V Battery vmon2: 7.362 V Wall voltage: 8.652 V Battery temperature: 25.03125 C Power mode: Battery power Charger state: Battery discharging Unless I misunderstand the battery icon and diagnostics screen, it does not appear that my battery is charging. If that's the case then I expect it to drain entirely and then possibly die... I have searched the forum and checked the wiki, but still do not have a good understanding (besides noting the battery icon should be 'animated') what to look for or which minimum firmware revision is necessary to ensure correct charging. Logitech, can you please advise whether there is a battery charging issue here and if so recommend a path for resolution? -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=79039 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] my red clockradio- first no radio, now no clock
jsclarke;548779 Wrote: My little red squeezebox radio- which I'd intended to use as a clock radio, has really become a pain. First- in these greener days- I don't want to run a 200 watt PC (running squeezecenter) to make a clock radio reliable. But- after 7.5- the audio streamed kept stopping (which is terrible for a device I own to help fall asleep). So- downgraded squeezecenter- downgraded to 7.4 on the radio- and get the persistent upgrade nags when connecting to mysqueezebox.com... But now- the screensavers stopped working too... so I can't see the time either when stopped, or playing. So first, no radio. Now, no clock. This thing's a dud! Anybody have any ideas on fixing this? Thanks in advance... John (ps- a Boom, 2 SB classics, and 2 Grace WiFi radios work great on the same net- and the radio is hard-wired to an ethernet connection, and I've tried changing the type of screensaver for each state and the time delay to every possible choice with no luck, and power-cycling doesn't help either...) This problem is real. I've got it too. Not sure if it's related, but at some point my 7.4.2 SBS installation upgraded itself to 7.5 without asking. Now the Radio and SBS are running different versions. You might want to check on that (despite the fact it makes no sense how a version mismatch would contribute to this particular problem - the Radio software truly does behave in ways one wouldn't expect)... I'll downgrade SBS to match the Radio version soon and see if that makes a difference. I've grown tired of chasing these types of issues (which don't seem to end). The recurring maintenance necessary of a consumer/user to keep the Radio functioning properly is extremely disappointing... I, for one, despite having the capacity/knowledge to jump in and modify the codebase, have been resigned to using the Radio with degraded functionality (like no clock display) because I'm not willing to spend the cycles incessantly chasing the newly created issues that are consistently popping up. In a nutshell, this problem is real (add it to the list)... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=78947 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] my red clockradio- first no radio, now no clock
Thanks for the pointer. Makes sense now, after reading the other thread. So, if you do have different SBS and Radio firmware versions, and one of them is 7.5 you will likely have this issue. I'll downgrade SBS (and hope it doesn't upgrade itself again, unsolicited - after changing any available settings to explicitly prohibit upgrading) and then reconnect from the Radio (either by power cycling or switching over to MySB.com and then back to SBS) to force time synchronization again. It sounds like this should fix this one... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=78947 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Local reliable alarm, what would be acceptable ?
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 existing implementation). These events wouldn't be particularly likely unless some action precipitated a server request to the Radio, but they would indeed be possible. You could do what has been suggested here, or the alarm application as it exists today could be fixed (with associated necessary synchronization enhancements in the Radio infrastructure). These changes will be difficult to make work properly in a vacuum, however, while the rest of the Radio software is changing (as seems to be the case). I've already directly offered my services to Logitech management in the context of this issue (and/or other Radio software improvements), but been met with silence... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=78920 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radio Alarm Useless!
bluegaspode;541865 Wrote: Though there are people who wouldn't/couldn't get their Radio back, fiddled a bit with the system and now have a rock solid alarm function. I can only speak of local server operation (which with the arrival of the Touch got very easy for anyone wanting to expand anyways) but also heard of people with MySB.com starting to have succeses. http://forums.slimdevices.com/showpost.php?p=541830postcount=19 As you are stuck with the Radio why not just try with the help of the forum people to pindown your problems. Though Marc might be right with the architecture, its not as worse as to allow 'activates at seemingly random times AFTER the intended time'. Never ever - so chances are your problem can be solved. On the other hand: Logitech is advertising the Radio pretty strongly as an alarm clock (though not a reliable one :D) ... so if the customer support 'admitted' it was 'beta' you have one reason more to give it back even outside of the 30days. Don't know the laws in US, but in Germany you can give back devices within two years when it has malfunctions that were there from the beginning. I also think Logitech will 'help' you getting it back when threatening to writing Amazon reports whatever. Be creative. Two directions with/without the Radio for you. Just choose. Valid points. I, for one, am at firmware version 7.4.2 on my Radios and not budging. I never upgraded to 7.5 and don't plan on doing so. I've learned already that when one is largely satisfied with the operation of the Radio that it is counterproductive to upgrade. While in doing so you may get access to some new feature(s) touted by Logitech, you are also directly jeopardizing the functionality that you've already become satisfied with. My alarm works fine, as I always use a local Squeezebox Server (SBS), never configure an alarm from the web page (only use the Radio front panel), and I originally fixed the alarm operation myself (quite literally). Most importantly, since a relatively stable release of the alarm code was included in the firmware I'm running (7.4.2) the basic alarm functions are reliable. There are still issues, like the periodic audio pop in advance of fade-in and occasional volume weirdness (which happen due to the architectural problems I discussed previously in post #14 on the other discussion thread), but those problems aren't bad enough to make the alarms unuseable. I can, of course, still expect additional alarm problems if/when I ever upgrade the version of either Radio firmware or SBS that I'm running here. However, Logitech made relatively minimal modifications to the band-aided alarm code I provided them to originally fix the alarm problems in version 7.4.1 of their firmware. They did indeed make changes to my code (which I warned against) for the 7.4.2 release, but the relatively minimal changes represented by that released firmware version in the context of the alarm applet when contrasted with the later firmware releases is exactly why alarms are far more stable in 7.4.2. Now, as Logitech continues to modify the alarm applet code and/or SqueezeOS (alarms depend heavily on the SqueezeOS software foundation underneath the applet) and/or SBS and/or MySB.com in later software updates the alarm operation will only become more unstable. If you want stable alarms then find a version of the SqueezeBox system that works and then don't move. This includes, of course, only using SBS and not upgrading that version either. Because of the way the alarm system is architected, changing the server code (whether SBS or MySB.com) can be expected to directly impact alarm operation. Don't forget that you will never be able to standardize on a particular version of MySB.com as your server (since Logitech is providing the server and always changing the MySB.com implementation/functionality transparently), thus you shouldn't use MySB.com if you don't want to risk alarm operation changing (and likely regressing)... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=78080 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Problem with alarm sound
(despite the time it takes to post these dissertations)... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=77883 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radio Alarm Useless!
Redsvg;541752 Wrote: I purchased a SBR to replace a very nice Receptor radio to use mainly as an ALARM!! I find that it activates at seemingly random times AFTER the intended time, so it is useless to me. I was otherwise happy with the radio and thought I may have been setting it incorrectly, but after a few days of careful use realize the alarm function is faulty. I have read the other threads about alarm problems and am running firmware 7.5.0. I finally called support and the nice gentleman admitted that it is a known bug in a beta feature!! How can Logitech advertise this radio as having an alarm when it is known to be problematic and is in beta testing??!! It is unuseable for me for the main reason I purchased it, but because I waited until after 30 days to investigate it (I'm at 42) they will not take it back! So goes my long respect for and purchaser of Logitech products. I hate to be the bearer of bad news, but... anyone who believes the alarm system will get better through the process of bug-fixing is kidding themselves. While Logitech doesn't seem particularly interested in spending the engineering cycles necessary to fix alarms to begin with (I've rarely seen a less responsive company, to be truthful), they probably couldn't really fix/band-aid the alarm system as it exists today properly anyway. The alarm problems manifest on the surface are genuine indications of the foundational problems underneath. It won't be possible for Logitech to stabilize the alarm system without first changing the basic nature of how alarms function. For more details you can see post #14 in this discussion: http://forums.slimdevices.com/showthread.php?t=77883page=2 The alarm system will be 'beta' (and untrustworthy, in my opinion) until it is rearchitected from the ground up. It will also continue toward greater instability every time the functionality is touched, due to how unstable the foundation is. Mark my words... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=78080 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Alarm should not go off if SBR is already playing Music
mpower9;540734 Wrote: I have had this happen to me as well. At the moment, I think the only way to deal with the problem is to press the alarm button on the front of the radio and deactivate the alarm before it goes off. Perhaps we should request this as an enhancement on the bug page. I'd suggest you don't bother, honestly. The current alarm implementation is obviously quite buggy and I strongly speculate it will not get better. On the contrary, I proffer that it will only get worse as modifications like this one are added (if Logitech even chooses to attempt such modifications, which I think unlikely and/or unwise at this point). Every feature enhancement like this one (despite the request's very reasonable character) ends up being a band-aid modification to the existing alarm implementation. Because the architecture of the alarm system is wrong (yes, I say that definitively and with absolute conviction), every modification to the current implementation proportionally increases the chances that a regression in operation will be introduced. You can see how unstable alarms are at present... If this feedback causes any consternation then please go do a search for all the work I did previously in the context of fixing the broken Radio alarm system before bothering to chastise me. Every time Logitech touches the alarm functionality it is regressed (as you can see through objective evaluation of feedback on this forum in the context of new firmware releases). There are multiple reasons for this, but the primary overriding reason is as follows: - The alarm system architecture is plain wrong. No amount of fiddling with either the server (MySB.com or SBS) or the client (Radio) is likely to resolve this situation, as that same fiddling is clearly introducing more regression problems than resolutions. This is typically the case when a client/server application of any kind is inappropriately architected at the outset. Some may dispute the fact that I fixed the alarm system once (as best as was possible, considering the inappropriate architecture that was already in place). Yet, irrespective of their protests (and of Logitech's modifications to my implementation, which I warned against), I did indeed band-aid the alarm system to work properly at one time for the firmware 7.4.1 release. Much of my alarm system band-aid implementation code remains in the existing distributed alarm system today (that implementation has been changed by Logitech, however). The reality is that no band-aid on the Radio firmware side would have worked for long, however (even if my band-aid had been unmodified before public release), while changes continued to the server side of alarm operation. There are too many variables at play in the Radio alarm system operation, and like any client/server application that is initially architected incorrectly it will invariably suffer from instability and creeping regression as changes are incrementally introduced. Re-architecting it wouldn't be such a difficult thing to do, but apparently Logitech lacks the combination of time and/or incentive to do so. I would do it myself, but frankly have already fixed the Radio alarm system once and am weary of beating my head against the wall. I won't volunteer again to do it on my own time... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=77945 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Problem with alarm sound
, if the Radio worked as a proper alarm clock and was rock solid otherwise I could see one of these units in an absolutely huge number of American households. Sorry I got carried away there. Guess I've kind of grown tired of watching the Radio platform be squandered. Strong words, I know... No offense intended... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=77883 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox 7.4.2 - what the HELL Logitech?
bluegaspode;525510 Wrote:
Why would I feel the need to defend 7.4.2. Every software (be it
devoloped from you, me or logitech) will always have remaining bugs
which need to be solved.
And I keep my oppion. Claiming that the few unknown bugs from now
wouldn't have happened with your code is just plain arrogant, pardon my
words.
When you are not able to convince people of important changes (or to
keep some lines of code), than part of the problem is definitely also on
your side.
{shrug} Arrogance is in the eye of the beholder, I suggest. You're
exhibiting some of your own with your comments, if I may be so bold.
Why don't you stop complaining about the purported shortcomings in my
(unwisely discarded) code and instead go fix the problems in 7.4.2 (the
way that I once did for 7.4.1)...?
bluegaspode;525510 Wrote:
I think its not just about the log messages in the applet.
The radio has a very nasty problem, that
a) its logfiles are to short and changes are overwritten too early.
this can be fixed ad hoc by using the instructions from here:
http://bugs.slimdevices.com/show_bug.cgi?id=15444#c43
b) its logfiles get overwritten, when the radio reboots or crashes
(horrible!).
About both I'm swearing often, because my radio also sometime gets into
strange states, where it disconnected from the network and only
rebooting helps. Gone are the logfiles :(
I tried to find a bug report for both, but couldn't find them.
That was exactly the point I was making about logging. The current
logging doesn't facilitate effective debug when important log output is
lost (because the logs are not big enough, not double buffered, etc.).
I was not alluding specifically to the alarm applet output...
Not sure what you mean in your last comment about a bug not being
filed, but I don't see why there needs to be one at this stage. One of
the first things done by a competent embedded development organization
is to develop/enhance a proper logging subsystem so that critical
crash/malfunction data isn't lost...
--
Marc
Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776
View this thread: http://forums.slimdevices.com/showthread.php?t=75541
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox 7.4.2 - what the HELL Logitech?
erland;525498 Wrote: Marc or bluegaspode, let's focus on the logging. We all know the history, there is no point arguing who is right and who is wrong. Marc, if I understand you correctly, we need some more logging to be able to track the problem ? I haven't looked specifically at the applet output in the context of tracking the alarm problems I've seen, Erland. When I spoke about logging being lacking earlier I was alluding to the fact that critical logging data is lost under a variety of conditions. The logging subsystem leaves much to be desired at the outset, which makes delving into specific problems difficult/impossible... In the context of the arguing, I think it's obvious at this point that I take offense to the denigration of my attempts to fix alarms in 7.4.1. after a variety of my suggestions were dismissed subsequently while instability remains. Then to try and blame my code for said remaining instability...? Talk about leaving a bad taste in the mouth... erland;525498 Wrote: If you have the time and inspiration (I can understand if you don't), it would be great if you could suggest where in the current version of the AlarmSnoozeApplet code in 7.4.2 we should insert these extra log messages. Logitech will of course still have to decide if they like to insert these log messages or not in the production code. However, if they don't we can still make a patch which can be installed through my Patch Installer applet so the people which often get the incorrect fallback alarm can provide the necessary log files to Logitech. The Patch Installer applet requires 7.5 firmware so we can't use that before 7.5 is out of the door, but anyone with the right knowledge can still install the patch manually. By the way, I've seen the incorrect fallback alarm on 7.5, so it's not just 7.4.2 that has this problem. Personally, I still feel that Logitech needs to take a look at the whole client/server architecture to solve this alarm issue completely, but if we can get it to work better with some small changes it could be a good temporary solution. Feel free to continue the development related discussions in the Developers section of the forum where it's a bigger chance that someone from Logitech sees the discussion. Unfortunately, I've little remaining inspiration at this point... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=75541 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox 7.4.2 - what the HELL Logitech?
bluegaspode;525205 Wrote: Marc, don't grumble, that's not true. I'd say that 95% of your suggestions made it in the final code - and the last 5% either didn't look important or you were not able to make your point (when at least two people were listening) why some scenarios would fail when these parts were done differently. Also some good things came from Ben like caching the snooze-time from the server or better/correct detection of failing audio. In the end Ben had a lot of testcases which he went through with the final implementation and I think its not fair to say 'If you had taken all of my code without questioning it wouldn't have happened' without providing prove of it or providing a failing testcase. We are all professional coders and should trust to make right decisions in the void that is left without testcases. Now the work is to find out what the missing cases are and as we have very good logging (and some user with problems) this shouldn't be too difficult. Though it's not good that the fallback alarm is maybe firing too often - its a good sign for reliablitiy (as it's better than a missing alarm). I didn't have any alarm problem yet though I'm waking up to it every morning - so I'm very interested to see some logs from the radio ! By the way - as logitechs focus has moved away from the alarm again I would spent my time only in documenting the failing cases but personally wouldn't look into the code again. Would be too depressing to wait for someone caring for that in the end (did that once for 4 month, also see thread starter, not again ;) ) I hear what you are saying, and you are right that Ben worked hard toward resolution of the alarm problems. Having said that, I disagree with some of what you stated above. Obviously, the alarm malfunctions I've witnessed in 7.4.2 are better than a missing alarm (no need for a specious argument)...I'll get the customary disclaimer out of the way [yet again] about how the underlying architecture is heavily flawed (the client/server aspect doesn't make sense in the context of how SC/MySB.com communicate with the Radio). The attempts I made to patch the existing architecture (it was clear a wholesale overhaul was not in the cards short term) for stability would indeed have resulted in a more stable alarm situation for 7.4.2. On that point we disagree. Enough has been changed such that I would need to largely begin anew in debugging/resolving. And for what...? Your good nature and useful input (along with that of others) served to greatly assist during the process. The environment here at the forums is compelling, as well (friendly, cooperative, etc.). However, there are indeed changes that were made to my modifications which were unwise. In the final analysis, alarms are still less stable than they should be... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=75541 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox 7.4.2 - what the HELL Logitech?
erland;525175 Wrote: Same thing has happened to me too a couple of times. Your efforts in the past are greatly appreciated, I can understand your frustration but I hope you change your mind. At the moment all Logitech resources are probably busy with the Touch release but after they have finished that it might be time to look at the alarm handing again. Thanks for the words of appreciation, Erland. They mean a great deal, particularly coming from you. I don't mind giving of my free time, but I'm not enthusiastic about giving such an effort when a good chunk of it appears to have discounted. -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=75541 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox 7.4.2 - what the HELL Logitech?
bluegaspode;525448 Wrote: I think its not fair to claim your patch was the best of all and everything done later was to the worse. Your change was a BIG step towards a very good solution on the given architecture, but also with Bens additional changes to your patch we have a much more stable alarm situation in 7.4.2. Maybe even more stable than your patch ? Who knows ? You are welcome to your opinion, of course. If anyone has the desire, time, and compunction to look back at the extensive conversation thread that took place in the developers forum then it's there for the perusing. Honestly, your comments are a pointed illustration as to why it makes little sense to keep working toward stability. Your 95% estimate of my changes that were incorporated is a poor one. My architecture was indeed used, but far more than 5% of the changes that I made were discarded. The devil is in the details, and the details were not respected properly when important pieces were discarded. This is particularly true in the context of how the client/server architecture used is/was unintuitive and more, rather than less, pedantic code is/was clearly a necessity to track and defend against unexpected behaviors. You are wrong, by the way, about the changes made to my modifications having increased stability. They did not, as evidenced by the problems that remain in 7.4.2. I warned specifically against sacrificing some of the state tracking I had added, yet my warnings went unheeded. It's true that you weren't convinced after much debate, though, so perhaps you still believe the right course was pursued. I admit that it's a bit offensive, though, when you say glibly that perhaps the changes I recommended retaining weren't up to the standards of the now disseminated 7.4.2 code - which is clearly still unstable. It would make sense for you to defend the now released 7.4.2 code, despite its continued instability, I suppose, since perhaps you feel the need to take some measure of responsibility for not being convinced of a number of the since discarded stability measures I lobbied for. bluegaspode;525448 Wrote: Without logs for the current minor hickups noone is able to tell, who is to blame. Remaining parts from the 7.4.1 code-base? Your original patch ? Bens later changes ? I attempted to get the log after the malfunction occurred (while I should have been headed off to work). Unfortunately, it had been quickly overwritten and was lost. I've also suggested that logging be enhanced to prevent this type of situation in the past, if you recall. bluegaspode;525448 Wrote: To make at least one logitech developer feel very comfortable with the current code :) It wouldn't make sense to take your changes as a 1:1 copy to make your debugging now easier ... its far more important that logitech feels comfortable with the code and is able to understand its current ideas on the long run. No one suggested a 1:1 copy of my work. The code I'm alluding to that was unwisely discarded consisted of specific state information that was tracked to enhance both stability and post-mortem analysis. Nor did I ever state or imply that 'everything after [my changes] was to the worse'. I'm afraid you're putting words in my mouth that I don't appreciate here... Ok, so now Logitech is ostensibly more comfortable based upon your commentary (not an unreasonable point). Are they now working on these new issues, whether making logging more useful to facilitate log feedback from customers by preventing log overwrites or by continuing to test alarms in 7.4.2? Has that development comfort translated into alarm robustness? I'm not going to get further into a personal defense of my work, nor of my history and expertise in embedded product development. Suffice it to say that I am not (and was not) guessing when it came to working toward alarm stability. Logitech as an organization has a lot to learn about both embedded development and client/server architecture... It's too bad, really, because I truly believe the Radio could be huge. bluegaspode;525448 Wrote: That being said - lets at least spend time in creating the appropiate logs for the current 'backup alarm even though the stream seems to be available' problem. Noone asks for or expects further debugging. If the logs were there then that would be possible... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=75541 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox 7.4.2 - what the HELL Logitech?
jmpage2;524897 Wrote: Continue to get backup alarm sound instead of my music playlist from SB Server 50% of the time on my SB Radio after update to 7.4.2 even after disabling nightly rebuild of my music libarary on my SB Radio. Interestingly this did not happen on 7.4.1 so obviously some fix for alarm reliability has broken my alarm. Does anyone know if a bug report has been filed yet on this? I also had a 7.4.2 alarm malfunction a couple of days ago. Backup alarm audio played even though the station selected for the alarm sound was working fine. I turned the alarm off and hit the play button then the station played fine. After that the alarm fired again (extraneously) and cycled between the backup alarm sound and the selected station. There is also a volume problem where the alarm audio level sent in by the server isn't properly coordinated with the locally set volume, so when you touch the volume dial the level jumps unexpectedly as the local volume level switches from the server provided volume to the local volume setting. I spent a great deal of time working toward the resolution of alarm problems in 7.4.1, unfortunately a good portion of my implementation suggestions were discarded. It's not worth banging my head against a wall my while sacrificing my own free time at this point... The good news is that I have yet to witness a set alarm that didn't actually fire in 7.4.2, even though the alarm behavior is still messed up. Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=75541 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox 7.4.2 - what the HELL Logitech?
eap;519692 Wrote: Its not that you leave a computer on 24/7 in order to have a reliable alarm clock, its that typical use of a computer could (nay, even should) contemplate 24/7 hour use of that computer. So the alarm clock is then just a bonus you get on top of that. I had my computer on 24/7 before I had any squeezebox product. So no change in behavior here. I am stunned at the apparent stubborn unwillingness of many here to spend a relatively small amount of money towards electrical costs (which would be many times less than a squeezebox over the course of a year), in order to have the convenience of on the demand Internet access, not to mention no worries over having to use the less worthy mysqueezebox.com . Why do we have fios and cable at blazing speeds if we don't leave computers hooked up to it 24/7? Has this Political Correctedness and green stuff really gone this far? When did leaving a computer on 24/7 become such a hardship? What is driving this ridiculous fear? Who wants to wait for boot up time every morning? And by the way, do we know exactly what 7.4.2 fixes -- the bug fix list for 7.4.2 says nothing about alarms last I looked a couple of hours ago? I'm not going to get into details here, since I've gone into plenty of them in the past in other threads at the developers forum. I haven't posted for a while, now that it looks like the alarm functionality is (read: should be) largely resolved in 7.4.2 going forward. After checking back today it was worth chiming in, however, based on a couple of things you wrote. I agree that it makes sense to leave the local SBS PC powered on 24/7 to avoid the set of problems that can manifest otherwise. This, of course, is an easy opinion to have when you already have a local server powered on 24/7 to begin with (as I do). In any event, I share this view. Something else you wrote prior in this thread is wrong, however. Yet, you shouldn't trivialize the number of real outstanding problems that exist with the Radio software. While I'm certain there are plenty of problems enumerated in this forum about the Radio that do relate to user error, there are also plenty of real ones that relate to the Radio (and server) software. I've seen them firsthand and even traced several down in detail. Some of the reason I've become scarce at the forum is because I'm not one to waste time in an environment where the cycles I'm applying appear to be in some measure ineffective. As an example, I posted a specific thread on how the synchronization of alarm notification trigger and server audio stream startup had/has a particular problem on occasion such that an audio pop is manifested prior to alarm audio being properly faded in (when that option is selected). This was after a variety of users had complained about said pop. It took me a couple of hours to trace and detail the problem on the forum. I provided plenty of information. To my knowledge, the thread (and problem) has remained unaddressed for weeks now subsequent to the details I provided. I'm pleased that alarms are about to fixed for a broad spectrum of Radio users, and not just for those of us who can trace down the problems and modify our own code (even in those cases, at the risk of a maintenance headache the makes future software upgrades annoying, if not prohibitive). I still run my own alarm code on 7.4.1, however, since I'm not interested in constantly bouncing between beta releases with new code updates. It's too time consuming, prior to an official release, especially when other annoying problems continue to manifest (for example, disappearing presets, etc.) and are not being addressed. It's good that Logitech applied developer resources/cycles to the alarm issues that are being resolved, but there is no shortage of additional problems outstanding. The user community can only do so much. Be assured that while certain problems exist that relate to user error (as you pointed out), you significantly understate the set of problems that exist due to software anomalies (unrelated to powering down one's server)... Doing so undermines your credibility and does not serve to enhance the Radio. Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=75541 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] NTP on Squeezebox Radio?
jdoering;506203 Wrote: Actually on second thought; it's another example of why the current alarm model is weird for smart squeezeboxes. I've followed the thread on that a bit but haven't digested it all. But the whole idea of the server sending an alarm signal sounds very silly. The radio is a smart device that could ideally keep it's own time very accurately via NTP. It can keep track of when alarms should sound without any intervention from the server. The only thing it should go to the server for is to get the actual audio at the correct time. If the server can't provide the data then the local fallback sound plays. But it's the same local logic driving the alarm either way. If the server wants to schedule an alarm it should submit the scheduled alarm to the Radio at scheduling time. That way the actual alarm is always local. If the server can't reach the radio to submit the scheduling then the operation should fail so the user immediately knows their alarm didn't work. Legacy thin-clients aside; I'm not sure why the alarms and radio time in general can't work this independently. But I'm not trying to turn this thread into another alarm issue rehash :) -Jeff Your points about how alarms function for the smart devices are right on the money, Jeff. Though the software model used for the new generation of devices certainly changed, it seems as though the software architecture wasn't necessarily reconsidered at the proper depth (at least in the context of certain system functions - alarms being a primary example). With the advent of more intelligence on the client side (which is indeed being utilized in many ways), some of these weird architectural decisions (whether leveraged from legacy thin device operation or not) may be responsible for certain problems that will be hard to get resolved. When the messaging model and architecture aren't carefully scrutinized/considered in advance, a client/server application can get woefully stuck in a maintenance quagmire as issues are incrementally patched up with band-aids. When/if the architecture isn't right to start, stability is not likely to be achieved this way. More likely is a spiral into instability, actually, as the failure cases become more complex... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=73808 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] In strange state: can't connect to any server
wxman;506115 Wrote: I was having a similar problem. I powered down my modem, powered down my router then restarted modem, restarted modem,and then connected from the radio to my music and all was well. Don't know why this worked, but it was the only thing that did. I ended up doing a reset to factory defaults. Was too busy chasing the alarm issues to get involved in debugging another issue simultaneously. I'll pursue the problem in detail should it occur again... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=73501 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Music before Alarm
I think Erland's and Stefan's comments are both probably important (Peter's as well, in pointing out to distinct issues in terms of the fallback alarm versus some earlier stream playing for a bit). I'd suggest doing a small bit of testing with the following in mind: You're playing stream 1 at some point in time and then think you've stopped it. It could be that when you think you've 'stopped' it that you really haven't, since hitting the pause button actually 'pauses' the stream. If the stream is then sitting there paused for hours prior to the alarm going off then there will be no surprise if you hear it again briefly when the 'server' alarm goes off (and maybe even if a fallback alarm fires, since it could be that encoded audio from the earlier stream has already made it to the Radio cache before you paused it OR that decoded audio - PCM samples - are themselves still waiting in the Radio cache from earlier). The reason you may hear the earlier stream briefly is due to how the notification system works. If a playerModeChange notification is delivered to some listening applet (or perhaps even just SqueezeOS directly determines the transition has occurred) which then decides that means to turn the local audio playout back on then voila... you are left with the previously played stream audio which was previously in paused state. playerModeChange notifications (along with several other similar type notifications) DO occur during the alarm process... So, see if a previously stopped (not paused) stream, as Stefan mentioned, manifests the issue when a later alarm is fired then retest with the played stream being paused (not stopped) prior to the later alarm firing... I would not be at all surprised if you hear just the alarm audio after the prior stream was stopped, but the brief earlier stream first if it was paused... Of course, if the earlier stream continues to be briefly heard prior to the requested alarm audio even after the earlier stream was explicitly stopped (not paused) then the problem is likely that either the cache/prefetch audio buffer at the server or the Radio is not being properly flushed after a stop operation. Either way, any existing audio (whether earlier paused or stopped) should, in my view, be flushed out of the playout pipeline when an alarm fires... Not so easy to do in the current context of how alarms work though... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=73708 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Music before Alarm
erland;504635 Wrote: I did some more testing regarding this and I think my problem is the volume ramp-up and not what's actually played. I've probably just been sleepy when a alarm has fired earlier thinking that there was some audio left in some buffer. Anyway, this is what happens: 1. I have the alarms configured to ramp up the volume with the Fade Alarms In setting. 2. I've paused the player, not stopped it. 3. When the alarm is fired it correctly selects the chosen playlist 4. It starts to play the music with high volume, I think it's the volume according to the alarm volume setting 5. After a half second it changes the volume to just above 0 6. It correctly ramps up the volume slowly until it reaches the alarm volume setting. The problem is step 4 which causes me to wake up immediately instead of through slowly ramped up music. It feels like step 4 and 5 should happen in the opposite order so the volume is lowered before the stream actually starts to play. If the player is stopped (not just paused) before the alarm sequence it works correctly. Also the problem is not what's in the buffer because it plays the correct track at step 4, it's just that the volume is too high at that moment. Makes sense. I think if you watch the log you will see in this case a playerModeChange or playerLoaded or playerCurrent or similar notification coming from SqueezeOS that is causing the audio subsystem to be prematurely transitioned to actually play out audio prior to when the volume is adjusted just above 0. Then again, you'll only see the notification occur if an applet or SqueezeOS is logging it. I know the new AlarmSnooze applet spits out these events, but I'm not sure they are otherwise logged... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=73708 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] In strange state: can't connect to any server
matengelen;502645 Wrote: Marc, I'm a noob to SB, so sorry if you've tried this already... But if not, it might fix your problem. Good luck ! PS: Or maybe a software update reset will do the trick ? Not a bad suggestion, but... 1) I don't want to lose the applets/favorites/etc... that I've already configured 2) I think I want to know what's causing it so it can be fixed and I don't end in the same state again sometime soon -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=73501 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] New 'alarm off' Feature/Change in 7.4.2 and 7.5
I actually like the screen the way it was, so I'm glad Ben is reverting the behavior. Leave it playing by doing nothing, snooze it, or turn the alarm off (and make the audio stop)... I, personally, really don't care about the 'now playing' screen while the alarm is ongoing (though I understand others may). I'd also like to see the alarm dialog stay there for as long as nothing is done by the user since I'd rather not be forced to take action before 60 seconds elapses, lest I lose the option to take action. Add a request for the clock (time) to be larger alongside (or under/over) the alarm dialog and I think I wouldn't have any complaints about the alarm activation UI... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=73506 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Safe to use as an alarm clock?
Alarms are MUCH more stable now. See this thread for details (if you care) and use the AlarmSnoozeApplet.lua applet attached in post #54 if you are interested in testing: http://forums.slimdevices.com/showthread.php?t=72871page=6 Regards, Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=73164 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Internet connection drop
I understand your frustration, as the (re)connection logic truly is the underlying cause of alarm instability. I also understand your doubt that the alarm problem can be fixed alone in the applet. If you have a look at what is actually going on under covers, technically, in the Radio when alarms malfunction you may have a different view though. These are not guesses I've proffered up out of some misguided sense of false hope. While I do hope Logitech actually pays attention to the detailed information I'm providing specifically as to why alarms are unstable and then uses that info. appropriately in short order, my posts are not just an attempt to prod the development guys (the *company* really, since it looks like those above the developers' pay grades have made the decision to prioritize other things besides Radio stability) into fixing the issues. Nor are my posts merely an attempt to make myself or others feel better about the situation because someone is actually looking closely at it. Let me be clear: I understand what's going on to the extent necessary to, I believe, stabilize alarms. It's not correct that the AlarmSnooze applet isn't started (or not receiving alarm set up requests), at least in the context of my testing. For what it's worth, I have yet to see a case where the originally provisioned (set up) alarm doesn't get to the AlarmSnooze applet (as long as the MySB.com webpage isn't used, that is, to set up alarms - see my note in next paragraph where I strongly discourage the use of MySB to set up alarms). You are correct of course, as Logitech development has themselves admitted now, about the underlying connection/reconnection behavior being at the heart of not only alarm, but also general Radio stability problems. It's true that my modifications to the AlarmSnooze applet are not (and won't be) elegant. They are (and will be) a workaround to the underlying general instability of Radio--server connectivity. The logic I've added to the applet has indeed made significant differences in alarm stability and I expect that they will be (cross your fingers!) reliable enough to use with confidence once you've installed the new applet. My strong recommendation for those connecting to MySB.com will be to entirely stop using the MySB.com webpage for provisioning (setting up) alarms in any form. In the MySB.com connection case, only the Radio dial/buttons should be used to provision alarms. If that suggestion is followed then I think that (while not elegant) Radio alarms will be stable enough to rely on when using the modified AlarmSnooze applet. Then, and this is the kicker, I (we) will head off to analyze/debug the underlying connection issues... :) Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72972 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Internet connection drop
The new releases coming (7.4.2 and 7.5) are very unlikely to resolve the majority of Radio alarm issues. There are many unambiguous technical details as to why Radio alarms are unstable. I have pinpointed the realities during my investigations and significantly improved alarm stability by modifying the AlarmSnooze applet. I've been communicating my findings and code changes directly with the Logitech developer responsible for chasing the Radio alarm issues over in the developer's forum. In Logitech's defense, there hasn't been much time yet for them to assimilate the information I've provided. We should give them a chance to look over my modifications and the information I've provided about what the detailed causes really are... My investigation/modifications will continue and I expect to have an applet ready for testing by others shortly. See this thread for *detailed* information on what the actual alarm situation is: http://forums.slimdevices.com/showthread.php?t=72871 Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72972 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Kidsplay: different behavior on same preset for separate Radios?
Won't be able to do much testing here in the short term, Peter, since my time is focused on fixing Radio alarm functionality. This is fabulous stuff, though! Thanks very much for this excellent enhancement. Maybe I'll be able to get some testing in next week sometime after my daughter has gotten her Xmas present (hint: the box is shaped like a Radio package). Until then the Radios in our house have been largely hidden from public view... :) Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72801 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Significantly more stable alarm applet
Hello, Ben...? -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72956 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Significantly more stable alarm applet
Have now moved commentary regarding development of Radio alarm changes/fixes to the development forum... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72956 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
[SlimDevices: Radio] Significantly more stable alarm applet
Ok, I've spent all too much 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. The Squeezebox development team will still be needed to help clean up the remaining issues (presuming they are interested in starting with my modified applet to begin with, that is). The remaining issues appear to be systemic, as I mentioned, and relate to flow control 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... To the Logitech team there: I still need information on licensing and distribution constraints to determine if it's ok to distribute this modified applet for testing by those who want to give it a try. Do you guys want to have a look at it in advance to examine and possibly run through a QA ringer? I'm also willing to talk about the specific issues that remain if you guys are interested... I believe I now have a firm understanding of what the remaining problems are and can share suggestions toward resolving them (not to be presumptuous). If and when Logitech approves the distribution of this modified applet for a group of interested Radio users to test, testers must understand that I have only been debugging this applet for 3 days now (albeit probably 30 hours in total by now). I've also only tested it in my environment, so it has had nothing near a real good shakeout yet. The optimal scenario would be that the Logitech guys have at it first, as I think it will provide them a good foundation for resolving the balance of alarm issues remaining. Ben, Michael, et al... Please advise how you'd like to proceed... Regards, Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72956 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Radio architecture question for Slim developers
bluegaspode;497583 Wrote: I'm no Logitech-Developer so what I'm writing might be wrong. I stumbled about the same things when I wrote an applet that used the Timer-Framework a lot and I wondered about the same things As far as I remember there is a (Single-Threaded) Main-Event-Loop which 'fires' all events (including Timer-Events). I'll try to find the corresponding classes in the evening (I am at work right now) I think I remember them lying around under the 'jive' package. I guess/hope that external events are queued as well so you won't have 'real' multithreading in the LUA-Applets themselfes. As I said I found these places when following the Timer-System (was it window.addTimer ??). As the HTTP Framework also works asynchronious (receiving the responses) you might also start there. The Flickr-Applet does HTTP-Requests so its a good starting point for further investigations as well. Ok, I think I see how the system works, in general, now that I've looked further at Lua coroutines. An explanation (albeit, a bit confusing) is here: http://lua-users.org/wiki/CoroutinesTutorial I do see sporadic use of coroutine mechanisms in some of the jive and lua code on the Radio, though the explicit use of these coroutine mechanisms is not very widespread. So, it looks like the system is using cooperative scheduling in a run-to-completion model. That is, it appears each thread runs either to completion (without interruption) or until it explicitly yields to other threads in the system by calling coroutine.yield(...) Now, where an applet does not explicitly yield (AlarmSnooze does not do so anywhere in the applet) the question that remains is this: where, if anywhere, does the underlying jive (or lua proper) code implicitly yield during a system call of some kind that is made from the applet? The point is that the applet can still yield to other threads when it makes another system call (which is defined elsewhere) which itself calls coroutine.yield(...) I don't think this behavior (where system calls themselves yield under the covers on behalf of the calling thread) is widespread, since I don't see too much use of yield in the jive foundation classes. I'm going to presume for now that this implicit yielding does not occur... Ok, I've poked around some more and see how both the timer and notification callbacks work. The main handling loop is defined in the UI framework and both notifications (via processEvents()) and timer callbacks are handled serially. So, everything does indeed look good in terms of thread-safety. I should never have doubted the Logitech guys in the context of system thread safety! :) Now I feel comfortable continuing on in the hardening of the AlarmSnooze applet. I've got some stuff to do today, but should be able to work on it again later tonight. Is there any licensing issue with modifying and then redistributing a Logitech provided applet? I don't see any reference to licensing in the AlarmSnooze applet code itself... I'll report back once I've had a chance to further harden and test the applet. I'll likely need some people who are willing to do their own testing with it as well (once it's ready for that), since it's very unlikely that I'll be able to test all the code paths in my own environment. I will be certain to heavily instrument the first distribution for troubleshooting purposes so that when logging is turned up for the applet there will be little doubt about what has transpired in problem cases... Marc -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72871 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
[SlimDevices: Radio] Kidsplay: different behavior on same preset for separate Radios?
I've got Kidsplay installed (very nice tool, Peter, thank you), but am wondering if there is a way to bypass the global preset button behavior that seems to be required...? Global behavior is very useful in some cases, but context sensitive behavior is certainly needed too. I understand that if no playerid is specified in the macro defined in the Kidsplay settings that only the current Radio is affected, unfortunately this doesn't seem to be adequate unless the user desires ALL Radios connected to Squeezeserver to have the same behavior on all preset buttons. I've got two SBRadios here, and want global behavior (which works very well, and as expected) on button 1 (sleep function) for both Radios. However, I don't want global behavior on the other 5 preset buttons. I've looked at the CLI documentation as well as the Kidsplay documentation. I do see how you can instruct ALL Radios to do the same thing when pressing a button, and I also see how to instruct a specific player (or all other players) to take a particular action. Is there a way, though, to instruct two separate Radios to run two separate macros (or portions of a macro) when a particular button is pushed at that particular Radio? I'd like to have button 2 set to play playlist1 if pressed on Radio1, but have button 2 set to play playlist2 if pressed on Radio2. I see a way to force Radio1 to play playlist1 and Radio2 to play playlist2 when I press button 2 on EITHER Radio (by essentially writing one macro that specifies two distinct playlists using the appropriate Radio-specific playerid's). This behavior isn't what I want, though. I'd like both Radios to have access to distinct functionality on the same preset button and not force some behavior (as defined in the macro) Radio2 when button 2 is pushed on Radio1. I see a way in the CLI docs to query the current playerid, but I don't see a way to conditionally use that playerid to qualify the macro attached to a button. So... is there some way to request the player id via the CLI commands and then conditionally run a particular portion of macro behavior (as defined globally on a particular preset button under the Kidsplay settings) based upon the id of the current player where the button is being pressed? Hope that makes sense. Thanks for all info... -- Marc Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72801 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
