davenva;541096 Wrote: > It's interesting that the log has the radio talking to mysqueezebox.com. > I keep the radio connected to my local squeezebox server, not > mysqueezebox.... > > I think that I read somewhere that the "natural" alarm sounds come from > mysqueezebox? Could that be why it goes there? > > It's odd enough that an alarm function needs a server at all, but > involving 2 different servers is beyond odd. One would think that a > radio with a computer inside would be smart enough to simulate an alarm > clock all by itself....
Correct. And agreed on all fronts. Many of the problems in the Radio software (because there are indeed many) stem from a couple of different angles. I know because I've delved into the code base quite deeply. While the alarm function is generally the most overtly seen to be problematic (for reasons involving criticality of the alarm function), that subsystem suffers from problems that are fundamentally more widespread in the Squeezebox Radio software foundation. The layers of functionality are not intuitively distributed, and the information passed between them doesn't always make sense or satisfy a need of an adjacent logic layer. Frankly, the interfaces and applications don't appear to have been coordinated in a fashion that makes a ton of sense. Much information is not easy to get to from the applet arena, and the Squeezebox central operating infrastructure (SqueezeOS, I think it's called - I've paid more attention to how it works) often acts and reacts in opaque ways that are neither foreseeable nor recognizable by applets. Since much of the Radio functionality is implemented at the applet layer, the lack of information often available to the applets makes it hard to build a lot of intelligence or fault tolerance into whatever particular functionality an applet owns. Additionally, serious shortcomings exist in the area of synchronization. Proverbially speaking, the left hand is often unaware of what the right hand is doing. An applet may be waiting for a local Radio software timer to expire and then start to play out a locally stored audio file (as in the case of the alarm system), while the server (whether MySB.com or SBS) is simultaneously sending an inbound message to the Radio which is itself determined to usurp the playout subsystem for its own purposes... This is exactly the primary issue, by the way, in the context of why alarms don't work right on the Radio. Overall, synchronization is a widespread and significant problem under the covers of the Radio. You'll see in another thread just updated recently that a particularly adept user has gleaned from the logfile that his Radio seemed to be talking to both his local SBS and public net based MySB.com at the same time. This happens frequently, and can be viewed in the perspective I shared above about synchronization problems within the Radio software itself. Those synchronization problems also exist across the Logitech SB network infrastructure as well. The left doesn't know what the right is doing... but they are both tweaking the same dial... Not a recipe for stability. Additionally, shared resources in general aren't handled the way they are typically in an embedded system. Of course this is my opinion, but then again I've built quite a large number of comparatively complex embedded systems over the years. These products included many of the same functional software blocks that are utilized in the Radio environment. The network application architecture is itself suspect in several areas. Again, the best example may be the alarm functionality - where the entirety of application logic outside of time synchronization and a streaming service call should reside local to the Radio implementation, yet where the server provides the actual primary alarm trigger via message to the Radio instead. Make no mistake, though, these types of problems aren't isolated in the Radio software. The volume handling is odd and crashes into itself too, when the Radio attempts to modify state locally even as some logic path separately invoked because of a server message is messing around with the same thing. The playout subsystem suffers from this problem in general, where you can't be confident from the applet space that what you've requested of the OS is being honored... There's more, but I'm sure everyone reading agrees that I've said plenty by now. It really is a shame, as the Radio is truly a fabulous piece of hardware and a great and compelling service platform. It would be a VERY COOL device if the software was thoughtfully built and the operation both stable and understandable. I'm starting to get the feeling that Logitech really doesn't really care about this product space. I truly believe they are squandering a huge prospective market of untapped consumers. At the current price point (which is also fabulous), and with the proliferation of both broadband and consumer 802.11 wireless adoption, 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
