Home of the Squeezebox™ & Transporter® network music players.
Page 4 of 27 FirstFirst ... 2345614 ... LastLast
Results 31 to 40 of 264
  1. #31
    Ne'er-do-well, Vagabond bklaas's Avatar
    Join Date
    Apr 2005
    Location
    Minneapolis, MN
    Posts
    2,034
    Peter, you make frequent excellent contribution to the development forum, so I want to preface this by saying that I don't want this to come out as a flame. But, why are you writing several paragraphs about architectural mistakes in an environment that you clearly initially indicate you don't have any detailed knowledge of?

    This point needs to be made, BOLDLY, because I think it's being missed not just on this thread but elsewhere: There is NO INTENTION of having an alarm on Squeezebox Radio that requires the network to be up at the alarm time. The design is intended to sound an alarm even in the event of the server connecting being absent. This is no different than the design for the ip3k-based Squeezebox Boom.

    There are problems being reported by some in the field that the alarm is not reliable, and those problems need addressing. I am giving full acknowledgment to that. But the idea that the alarm issues are the result of having a code design that's dependent on the network to be working at the time of the alarm is 100% FUD.

    Marc, something you keep bringing up is that "the internet will be the internet", and of course that's true. But why is our current alarm design flawed in this respect? There is a fallback timer that's set at the time the alarm is set. When the server-side alarm comes due, whether the server is connected or not, an alarm should sound (if the server is disconnected it sounds an audio file stored locally in the firmware). Why is this a logical failure in design?

    Sorry, but I'm still 100% of the opinion that the bugs to be worked out, while present, are not due to a flaw in software architecture. After I return to work January 4th, I will take a closer look at the "sledghammer" method you put into your version of the applet, but my initial look at it made me think there was something you were not understanding about the basic idea of the server-side alarm model.

    Last note: multiple alarm "pipelining" issues are a good topic to bring up, but not yet. My goal right now is to get the basic use case working reliably.

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

    http://www.last.fm/user/bklaas/

  2. #32
    Quote Originally Posted by bklaas View Post
    Peter, you make frequent excellent contribution to the development forum, so I want to preface this by saying that I don't want this to come out as a flame. But, why are you writing several paragraphs about architectural mistakes in an environment that you clearly initially indicate you don't have any detailed knowledge of?
    Thanks for the kind words. The respect is mutual, as I hope you know. Why am I writing? Because I care -- it's not rational, I know, but I actually do care.

    This point needs to be made, BOLDLY, because I think it's being missed not just on this thread but elsewhere: There is NO INTENTION of having an alarm on Squeezebox Radio that requires the network to be up at the alarm time. ... the idea that the alarm issues are the result of having a code design that's dependent on the network to be working at the time of the alarm is 100% FUD.
    My comments and concern are largely based on comments you've made in this thread: comment #25: "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." and comment #27: "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." You seemed to repeat the idea again:

    Sorry, but I'm still 100% of the opinion that the bugs to be worked out, while present, are not due to a flaw in software architecture.
    What I keep deducing from your words is that you believe the software is fine, and the network problems are making the alarms unreliable. Am I misreading? Is it that you believe that the Lua/SqueezePlay architecture is fine but some MySB/Perl bug is causing MySB to actively send information to the players that messes up the alarms? There's certainly nothing you (on the player/Lua/SqueezePlay side) can do if MySB is sending bad info, but "connection problem" to me sounds like something different.

    I don't want to wage a battle of words over this, just respond to your question of why I bothered to write. I hope that you agree with my comment that "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."

    Last note: multiple alarm "pipelining" issues are a good topic to bring up, but not yet. My goal right now is to get the basic use case working reliably.
    Cool.
    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

  3. #33
    Senior Member
    Join Date
    Dec 2009
    Posts
    137
    Quote Originally Posted by bklaas View Post
    Marc, something you keep bringing up is that "the internet will be the internet", and of course that's true. But why is our current alarm design flawed in this respect? There is a fallback timer that's set at the time the alarm is set. When the server-side alarm comes due, whether the server is connected or not, an alarm should sound (if the server is disconnected it sounds an audio file stored locally in the firmware). Why is this a logical failure in design?
    I think you took my comments out of context, Ben. I never said that there is 'a logical failure in design', or, frankly, anything like that. I've done nothing but point out that the alarm *implementation* is broken. I've talked in detail about what is *broken*, not what is wrong with the design. As a matter of fact, if you look back through all of my (admittedly voluminous) comments I suggest you will not find an instance of me indicting the design. To be sure, however, I have indeed pointed out that the implementation is quite broken (and not necessarily just the AlarmSnooze applet). I've also provided specific details in several respects as to just how it's broken. It's nothing personal (and I ascribe no personal blame to anyone there at Logitech), yet that doesn't change the fact that Radio alarms don't work reliably, and the implementation is broken. When I've talked about 'systemic problems' maybe you've misconstrued what I meant. That doesn't mean I'm complaining about the design at all. It means that the system is broken and that the alarm problems are not necessarily centered just at one spot (like the AlarmSnooze applet). Instead there are disparate parts of the 'system' that are not communicating/cooperating effectively so as to facilitate working alarms. That's quite different than a design indictment. This is an important distinction in my mind...

    What I did point out in a previous response to a particular point you made was as follows: When you spoke about your belief that the connection problems were at the heart of the alarm matter and that fixing them would go a long way toward resolving the alarm issues, I agreed. I also, however, pointed out there are other things wrong that will also have to be resolved; thus, the alarm issues won't, in my opinion, be resolved solely by fixing the MySB connection instability issues. I maintain that position, and further reiterate critical supporting details below in response to your comment about my sledgehammer method (I'm ok with calling it that and will follow your lead) likely being the result of something I misunderstand...

    Quote Originally Posted by bklaas View Post
    Sorry, but I'm still 100% of the opinion that the bugs to be worked out, while present, are not due to a flaw in software architecture.
    At the risk of sounding redundant, I'll respond to this again because you raised it twice in your message... I have not personally spoken to a flawed software architecture, so I'm not clear on why you are harping on this point. You seem to be directing this at me (at least, amongst others), I'm guessing, since you mentioned in the previous paragraph that I *have* indicted the Radio software design. To be clear, again, I have not. I've only spoken up about how/why the implementation doesn't work. It's really not fair to extrapolate my attempts to help pinpoint the implementation flaws into my having proclaimed the architecture as wrong/flawed. I'm not sure how you came to that conclusion, honestly. And, to be truthful, I don't appreciate being misquoted (especially while I'm only trying to help reconcile the alarm problems, even if only temporarily, so they can be relied upon until such time that Logitech can get around to fixing the issue comprehensively)...


    Quote Originally Posted by bklaas View Post
    After I return to work January 4th, I will take a closer look at the "sledghammer" method you put into your version of the applet, but my initial look at it made me think there was something you were not understanding about the basic idea of the server-side alarm model.
    Of course there is the chance that I misunderstand something about the server-side alarm model you guys are using. Then again, I'd argue if it's true it would be a defensible misunderstanding since the behavior of the server (when it's MySB) is often inconsistent and confusing. Also, the lack of synchronization for provisioned alarms between the Radio and MySB (as in, they show different alarm settings) further confuses the issue.

    Nevertheless, the sledghammer method has little relationship to anything related to the server-side alarm model. I don't mean to be glib, but I would suggest there's a better likelihood that instead you misunderstand what I'm doing with the sledgehammer method. I thought I had explained it previously, but I'll briefly do so again so there is no misunderstanding going forward.

    The 'sledgehammer method' is only used in essentially ONE case:

    1) when the RTC fallback timer has previously fired because MySB/SBS either wasn't there or was otherwise incapable of triggering the alarm

    The 'sledgehammer method', when invoked, does ONE important thing:

    1) it attempts to wrestle back the local player/audio subsystem from whatever SqueezeOS component(s), or other applet(s), have mucked with the local player and/or audio subsystem while fallback alarm audio is supposed to be playing or is soon to be playing (as in the fallback snooze period).

    Let me be clear once more as to WHY this necessary. During the automatic reconnection process there is some software on the Radio that is reconfiguring or otherwise messing with the local player and/or audio subsystem to the extent that currently playing or soon to be playing fallback alarm audio may be screwed up. This will continue to be a problem until someone understands when, why, and how the local player and/or audio subsystem is being munged with. Until that time (which is not likely to be soon, I think most all will agree), the best possible solution to the above problem is what I called the sledgehammer: That is, after a short delay (currently ~1.5 seconds) that hopefully allows whatever software on the Radio that's messing with the local player/audio subsystem to complete that process, the 'sledgehammer' *subsequently* attempts to wrestle back control of the local player/audio subsystem so that fallback alarm audio can actually be heard by the Radio user who desires alarm audio.

    This method is obviously a workaround, but until the reason(s) as to why/how the critical audio playout path is being messed up are understood and resolved, how is a user supposed to trust the Radio to actually play alarm audio when this not-infrequent problem manifests?

    I hope it's clear now what the sledgehammer method is doing. Not the least of which is important because I argue it will help you, and whoever else is examining the alarm issues at Logitech, understand just *what* is going wrong with alarms now. To this juncture I haven't gotten a good sense that you guys really do understand just *what* is going wrong with alarms.

    Please don't get upset because I'm pointing out [at least some of] what is actually going wrong. I'm not guessing... I've seen it, recreated it, and am trying to work around it so that alarms can be trusted...

    Quote Originally Posted by bklaas View Post
    Last note: multiple alarm "pipelining" issues are a good topic to bring up, but not yet. My goal right now is to get the basic use case working reliably.
    Absolute agreement.

    Marc
    Last edited by Marc; 2009-12-26 at 18:12.

  4. #34
    Senior Member Philip Meyer's Avatar
    Join Date
    Apr 2005
    Location
    UK
    Posts
    5,596

    Radio architecture question for Slim developers

    Ben, are alarms server or player-based for Touch/Radio? i.e. If I configure an alarm whilst connected to SBS, and then switch to another server (or even MySB.com), will the alarm still sound? At alarm time, will it reconnect to SBS, and if not available play some backup sound, or is the intention to sync alarms via MySB.com?

    Also, will an alarm send a WOL packet a couple of minutes before the alarm time?

    Just wondering, as I haven't tried alarms on Radio/Touch much.

  5. #35
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,042
    Quote Originally Posted by Philip Meyer View Post
    Ben, are alarms server or player-based for Touch/Radio? i.e. If I configure an alarm whilst connected to SBS, and then switch to another server (or even MySB.com), will the alarm still sound? At alarm time, will it reconnect to SBS, and if not available play some backup sound, or is the intention to sync alarms via MySB.com?
    I believe there is some synchronization going on because my alarms are available on MySB.com even though I've only configured alarms when I've been connected to my local SBS. My local SBS alarms are configured to trigger a Dynamic Playlist playlist which obviously isn't available on MySB.com, so the alarms on MySB.com seems to be configured to use some default playlist "Musical Sounds/Barn Fire" (at least when I'm looking at them through the MySB.com web interface).
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  6. #36
    Senior Member Philip Meyer's Avatar
    Join Date
    Apr 2005
    Location
    UK
    Posts
    5,596

    Radio architecture question for Slim developers

    >I believe there is some synchronization going on because my alarms are
    >available on MySB.com even though I've only configured alarms when I've
    >been connected to my local SBS.
    >

    I guess you have "mysqueezebox.com integration" setting switched on then? Is it on by default? I think I switched mine off, because it messed up things like screensavers (eg. I have eg. MusicInfoSCR configured for now playing, which isn't available on mySB.com, so it chooses Blank, and syncs that back to SBS).

    >My local SBS alarms are configured to trigger a Dynamic Playlist playlist which obviously isn't available on
    >MySB.com, so the alarms on MySB.com seems to be configured to use some
    >default playlist "Musical Sounds/Barn Fire" (at least when I'm looking
    >at them through the MySB.com web interface).
    >

    My local alarm is also configured to use a dynamic playlist, so I wondered what would happen.

    This is a SB3 alarm, and for the rare occasion when I've switched to MySB.com and left it connected, I've set up another alarm for the same time in MySB, choosing a better alarm, eg. a loud internet radio station. So, personally I don't want to sync settings - my SBS alarm can't work on MySB, and wouldn't want my MySB alarm to overwrite my SBS alarm.

    I thought that Touch/Radio may be more intelligent, and switch to a different server if necessary. i.e. if alarms were player-based, rather than server based.

    Incidentally, my alarm configured to play Spicefly SugarCube as a Dynamic Playlist hasn't been working too well over the last week. 50% of the time the alarm fires but doesn't play anything - screen reports Now Playing, but there's nothing in the playlist. If I play the dynamic playlist manually, it always works. I'm wondering if any changes to the alarm code mentioned here have made things worse in this area.

  7. #37
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,042
    Quote Originally Posted by Philip Meyer View Post
    >I believe there is some synchronization going on because my alarms are
    >available on MySB.com even though I've only configured alarms when I've
    >been connected to my local SBS.
    >

    I guess you have "mysqueezebox.com integration" setting switched on then? Is it on by default? I think I switched mine off, because it messed up things like screensavers (eg. I have eg. MusicInfoSCR configured for now playing, which isn't available on mySB.com, so it chooses Blank, and syncs that back to SBS).
    Yes, I have mysqueezebox.com integration enabled, I don't remember changing it so I think it's the default.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  8. #38
    It seems to me that the mysb.com Europe problems are a blessing in disguise for the alarm issue (particularly for us non-European customers who don't have to live through them first-hand). For the FUTURE (not necessarily the present) of the product; infrequent alarm failures sound much scarier than widely-reported ones.

    This is an interesting thread and it sounds like the various developers are aiming in the same direction. I too was concerned about some of the suggestions that things with alarms would get better with connectivity fixes. In terms of bad-PR it's understandable. But technically if connectivity matters at all there's a huge problem based on how I expect an alarm to work.

    I don't use mysb.com but I greatly appreciate the ability to configure everything from SBS (see the thread and bug related to limitations there). So I hope the negative comments about doing it from mysb.com don't impact this functionality from SBS in the future. I guess the technical challenges there may be fundamentally different for MYSB as SBS should easily be able to either guarantee the device was updated with the alarm (and fail to set completely if this can't be achieved due to local connectivity issues). I suppose MYSB has to support a more disconnected model? That does sound fundamentally problematic for something like a reliable alarm. I don't want to have to trust that thingss will correctly synchronize sometime in the future before now and the time the alarm should fire - I want an immediate guarantee with fail-fast behavior. My apologies if I'm misuderstanding how the models work in general...

    -Jeff

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

    Latest AlarmSnooze applet

    Ok, so there doesn't seem to be too much interest by others in testing a new AlarmSnoozeApplet.lua

    Since I only see two views of the most recent applet I posted (not sure if that also represents how many downloads there have been, but I presume so), I'm not going to bother with any more incremental updates going forward. I'll post another version if I feel like I'm at the point where the alarms are totally stable (they are 90% better now), or when Ben or other interested party asks...

    The attached applet is the best one yet. Plus, I wanted to be sure that Ben has my most recent changes to evaluate once he gets back from vacation.

    I've incorporated Ben's model of always switching to the local player at the last possible moment before sounding alarm audio, and also made other minor changes to best ensure the trustworthiness of fallback alarm audio. The key problem remaining is that the Radio volume continues to be modified under the covers by SqueezeOS during the automatic reconnection process (though I attempt to always force it back if fallback audio playout is required). The detailed information spit out to the log by this applet will always pinpoint specifics in terms of what's happened under the covers to help post-mortem analysis of remaining alarm issues.

    If you decide to test then remember to NEVER use MySB.com to configure/setup/provision alarms. If connected to MySB.com (instead of a local SBS) then always configure/setup/provision alarms directly using the Radio dial/buttons...

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

  10. #40
    Senior Member bluegaspode's Avatar
    Join Date
    Jul 2009
    Location
    Berlin, Germany
    Posts
    3,229
    Marc,

    before going into testing I want to ask again, that you describe against which scenarios you 'hardened' the applet.

    Without knowing I had to test into the blue, which I definitely don't have time to.

    So please describe, what didn't work before your work and what should work now.
    I also think it's very useful to exactly document what didn't work before, as I hope that all these cornercases make it into testplans of logitech QA (or at least help Ben to decide if he can find even better ways to tackle the problems you found).
    Last edited by bluegaspode; 2010-01-01 at 04:59.
    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

Posting Permissions

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