Home of the Squeezebox™ & Transporter® network music players.
Page 13 of 27 FirstFirst ... 3111213141523 ... LastLast
Results 121 to 130 of 264
  1. #121
    Senior Member bluegaspode's Avatar
    Join Date
    Jul 2009
    Location
    Berlin, Germany
    Posts
    3,229
    Quote Originally Posted by Marc View Post
    Good thoughts, Stefan, but it will cause significant pain to reset state to 'alarm off' at snooze time. Doing so will change a large percentage of the logic already contained in the applet and I think will be asking for trouble.
    Actually I'm not changing much I think ... all methods stay as they are ... the only change I proposed is to include a 'stopAlarmAction' which will point to one of the existing 'alarmOff' or 'snooze'-function and will be called on window close.

    If the applet is in control instead of directly calling a function it now has to set a pointer and call window.hide().
    If the applet is not in control we have a fallback as the pointer is pointing at 'alarmOff' by default.
    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

  2. #122
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    11,042
    Quote Originally Posted by Marc View Post
    If it's acceptable that some alarms get screwed up then what else can be said, except that aggravated Radio users who don't trust their alarms will remain...?
    Is there some problem with MySB.com related to alarms even if a user don't do any alarm configuration on MySB.com web site ?

    If it only affects users that configure alarms through MySB.com web site I personally think people will accept to not use MySB.com web site to setup alarms.

    Also, if this is the case and I understand this correctly, it means that the MySB.com change doesn't have to by synchronized with the Radio firmware release. It would be okey to first release the Radio firmware and then a bit later do the changes on MySB.com when/if Logitech feels it's a good idea.

    If MySB.com causes problems even if the user doesn't use the web site to configure alarms the problem is more serious because then it's harder to instruct users how to avoid the problems.

    Of course, if it's easy for Logitech to decide to remove alarm configuration from MySB.com there is no reason to postpone it.
    Erland Isaksson (My homepage)
    Developer of many plugins/applets

  3. #123
    Senior Member
    Join Date
    Dec 2009
    Posts
    137
    Quote Originally Posted by bluegaspode View Post
    Actually I'm not changing much I think ... all methods stay as they are ... the only change I proposed is to include a 'stopAlarmAction' which will point to one of the existing 'alarmOff' or 'snooze'-function and will be called on window close.

    If the applet is in control instead of directly calling a function it now has to set a pointer and call window.hide().
    If the applet is not in control we have a fallback as the pointer is pointing at 'alarmOff' by default.
    I may have misread what you intended, but, when I saw you suggesting the change to state 'Alarm Off' in _alarmSnooze() I got concerned. This will change the logic more than it appears on the surface.

    Anyway, while you've presented another way to do the window handling, I think you've misunderstood the original problem being debated in the context of the pause button canceling an alarm. The real (and only) problem surrounding this situation is that hitting the pause button does not result in a menu operation taking place. Instead it results in a clear alarm ('none' and nil) directive being delivered to the applet (specifically at notify_playerAlarmState) via the SqueezeOS notification mechanism. The question is whether to respect it or to discard it...

    Marc

  4. #124
    Senior Member
    Join Date
    Dec 2009
    Posts
    137
    Quote Originally Posted by erland View Post
    Is there some problem with MySB.com related to alarms even if a user don't do any alarm configuration on MySB.com web site ?

    If it only affects users that configure alarms through MySB.com web site I personally think people will accept to not use MySB.com web site to setup alarms.

    Also, if this is the case and I understand this correctly, it means that the MySB.com change doesn't have to by synchronized with the Radio firmware release. It would be okey to first release the Radio firmware and then a bit later do the changes on MySB.com when/if Logitech feels it's a good idea.

    If MySB.com causes problems even if the user doesn't use the web site to configure alarms the problem is more serious because then it's harder to instruct users how to avoid the problems.

    Of course, if it's easy for Logitech to decide to remove alarm configuration from MySB.com there is no reason to postpone it.
    I found it very hard to get to the bottom of *exactly* how MySBS works in the alarm configuration/handling context. During my limited testing the results were very inconsistent. It would likely have taken many full days (and potentially longer) of testing to determine just what MySBS would do in a variety of different cases. I did see cases where alarms were totally cleared ('none' and nil sent to applet) after the MySBS connection was established, even though there was an alarm previously configured and present at the Radio. So, if the question is 'how does MySBS work in the alarm cases?' then I do not have answer beyond this one: 'Not properly or consistently'...

    You're right that, in any case, the current applet makes alarms far more reliable than they were.

    Marc

  5. #125
    Senior Member bluegaspode's Avatar
    Join Date
    Jul 2009
    Location
    Berlin, Germany
    Posts
    3,229
    Quote Originally Posted by Marc View Post
    Instead it results in a clear alarm ('none' and nil) directive being delivered to the applet (specifically at notify_playerAlarmState) via the SqueezeOS notification mechanism. The question is whether to respect it or to discard it...
    I wasn't aware, that you ignored this event by intention, as you got this event also at unwanted times (damn!).

    You are right - if one handles this event also with my new proposal the alarm would stop maybe at unwanted times.

    Lets stop discussion until monday, otherwise Ben won't be able to catch up
    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

  6. #126
    Senior Member
    Join Date
    Dec 2009
    Posts
    137
    Quote Originally Posted by bluegaspode View Post
    I wasn't aware, that you ignored this event by intention, as you got this event also at unwanted times (damn!).

    You are right - if one handles this event also with my new proposal the alarm would stop maybe at unwanted times.

    Lets stop discussion until monday, otherwise Ben won't be able to catch up

    I'm not sure we can even catch up anymore despite being around...

  7. #127
    Ne'er-do-well, Vagabond bklaas's Avatar
    Join Date
    Apr 2005
    Location
    Minneapolis, MN
    Posts
    2,034
    Quick summary thoughts, but I've not fully digested the volume of responses nor will I until Monday (I have two little girls that on weekends pretty much solidly thwart any attempt at reasoned thought)

    - Yesterday I checked in a change on the server-side that removes, for squeezeplay-based players, the 20 second check for the server-side fallback alarm. Hence, all fallback on alarm in Squeezebox Radio is client-side, as advised. That code may take a bit to percolate up to mysb.com, but in an subversion updated 7.4 SBS, it's already done.

    - Erland's point about too much complexity is one that I'm trying to consider very strongly, both in terms of getting the alarm reliably working but also in hopes of having an easily maintainable applet. Obviously though, at a first order it needs to work reliably, and in the absence of a consistent behavior from the server notifications (to be honest, I think these are being wildly overstated but I will concede there are instances of inconsistency), something has to be done to stabilize.

    - I'm in full agreement with bluegaspode that we're actually not far off from having this in a pretty good state. Towards the end of the week the key thing I was homing in on was that I wanted assurance that state variables like self.alarmInProgress were being properly set, which in certain situations they are not.

    I was actually expecting to have this work checked in days ago, but given the relative complexity and remaining unresolved issues (some which actually cause regressions from the released code), I'm opting for the conservative approach and have not checked anything in yet. It will be significant for me to get something into subversion because the passing back and forth of full applet code is only serving to muddy the waters right now.

    I'll be focused on this again Monday.

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

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

  8. #128
    Senior Member
    Join Date
    Dec 2009
    Posts
    137
    Quote Originally Posted by bklaas View Post
    Quick summary thoughts, but I've not fully digested the volume of responses nor will I until Monday (I have two little girls that on weekends pretty much solidly thwart any attempt at reasoned thought)

    - Yesterday I checked in a change on the server-side that removes, for squeezeplay-based players, the 20 second check for the server-side fallback alarm. Hence, all fallback on alarm in Squeezebox Radio is client-side, as advised. That code may take a bit to percolate up to mysb.com, but in an subversion updated 7.4 SBS, it's already done.

    - Erland's point about too much complexity is one that I'm trying to consider very strongly, both in terms of getting the alarm reliably working but also in hopes of having an easily maintainable applet. Obviously though, at a first order it needs to work reliably, and in the absence of a consistent behavior from the server notifications (to be honest, I think these are being wildly overstated but I will concede there are instances of inconsistency), something has to be done to stabilize.

    - I'm in full agreement with bluegaspode that we're actually not far off from having this in a pretty good state. Towards the end of the week the key thing I was homing in on was that I wanted assurance that state variables like self.alarmInProgress were being properly set, which in certain situations they are not.

    I was actually expecting to have this work checked in days ago, but given the relative complexity and remaining unresolved issues (some which actually cause regressions from the released code), I'm opting for the conservative approach and have not checked anything in yet. It will be significant for me to get something into subversion because the passing back and forth of full applet code is only serving to muddy the waters right now.

    I'll be focused on this again Monday.

    cheers,
    #!/ben
    I won't get into a debate (though clearly I've stated my thoughts before) about the state of notifications or synchronization here, to avoid taking any more of your cycles where they could otherwise be applied toward stabilizing alarms (once you get back to work and have transitioned away from the right top priority - your kids)...

    I'll also try not to take it too personally when you say that some of the applet state isn't properly set and that regressions have been introduced when contrasted with the released code. I'm only human, though, so I will point out that I believe these statements are not generally accurate... {shrug}

    I've purposefully not further modified the code or provided any applet updates here to prevent muddying the water, as you mentioned...

    Marc
    Last edited by Marc; 2010-01-09 at 10:14.

  9. #129
    Senior Member ModelCitizen's Avatar
    Join Date
    May 2005
    Location
    Sussex UK
    Posts
    3,156
    Sorry for the unasked for interjection but Ben.... it is great that you are fixing the alarm but unless the bug below is fixed then then it still will not wake anyone up who falls asleep with headphones on. If you have any power to alert the powers that be (as the bug itself seems to be being ignored) then I (and a few others) would be very grateful if you could.

    No reply required.

    https://bugs.slimdevices.com/show_bug.cgi?id=14742

    Thanks

    MC
    Somewhere, something incredible is waiting to be known
    Last.fm/user/ModelCitizen

  10. #130
    Senior Member
    Join Date
    Dec 2009
    Location
    Germany
    Posts
    748
    Quote Originally Posted by bklaas View Post
    Quick summary thoughts, but I've not fully digested the volume of responses nor will I until Monday (I have two little girls that on weekends pretty much solidly thwart any attempt at reasoned thought)

    - Yesterday I checked in a change on the server-side that removes, for squeezeplay-based players, the 20 second check for the server-side fallback alarm. Hence, all fallback on alarm in Squeezebox Radio is client-side, as advised. That code may take a bit to percolate up to mysb.com, but in an subversion updated 7.4 SBS, it's already done.
    ...
    Since my last post promising some more logs I have runs into an interesting phenomen that still find myself unable to reproduce reliably. As it happened today again I am at least able describe what happened this time:

    1. The alarm (set on the radio itself) seemed to fire ok using a radio-stream
    2. The show being quite interesting I let the alarm run its course and it turned off the audio in due time. So far so good.
    3. After a couple of minutes I realized that the radio is no longer playing and I (think I) pressed one of the preset buttons to select a new radio stream.
    4. Instead of the music the local audio.mp3 starts playing. This audio can only be paused by selecting (and playing) another stream. Pausing this (or any other) stream restarts the alarm.mp3.

    5. The only way to stop the alarm.mp3 is to reboot the radio.

    I have updated my SBS to 7.4.2 - r29756 so the weird alarm behavior ought to be related to the radio itself as there no more server-based fallback alarms, right?
    Last edited by copperstate; 2010-01-10 at 04:26.

Posting Permissions

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