bklaas;506404 Wrote:
> Actually my fix is different than that. IMO the sledgehammer routine
> needs to check self.alarmInProgress to see if the hammer boolean should
> be true
>
> >
Code:
--------------------
> >
> === AlarmSnoozeApplet.lua
> ==================================================================
> --- AlarmSnoozeApplet.lua (revision 38121)
> +++ AlarmSnoozeApplet.lua (local)
> @@ -38,7 +38,7 @@
> jnt:subscribe(self)
> self.alarmTone = "applets/AlarmSnooze/alarm.mp3"
>
> - self.alarmInProgress = 'none';
> + self.alarmInProgress = nil
>
> local timeToAlarm
> local startTimer = false
> @@ -127,7 +127,7 @@
> self:getSettings()['alarmNext'] = false
> self:storeSettings()
> self:_setWakeupTime('none')
> - self.alarmInProgress = 'none'
> + self.alarmInProgress = nil
> -- might want to qualify whether or not to stop this timer dependent upon
whether it's already running.
> -- for now just log the information
> if self.RTCAlarmTimer:isRunning() then
> @@ -186,7 +186,7 @@
> --debug.dump(status)
>
> log:warn('alarm_sledgehammerRearm(', caller,'): ', self.alarmInProgress, '
alarm in progress - audioState is ', status.audioState)
> - if status.audioState ~= 1 then
> + if self.alarmInProgress and status.audioState ~= 1 then
> hammer = true
> end
>
> @@ -279,7 +279,7 @@
> log:info('notify_serverDisconnected: ', server, ' is now disconnected')
>
> -- blindly check state here irrespective of which server caused this
notification
> - if self.alarmInProgress ~= 'none' and self.alarmInProgress ~= 'rtc'
then
> + if self.alarmInProgress and self.alarmInProgress ~= 'rtc' then
> if not self.localPlayer:isConnected() then
> log:warn('notify_serverDisconnected: ', server, ' - while server alarm in
progress! state ', self.alarmInProgress, ' triggering fallback alarm!')
> self:openAlarmWindow('rtc')
> @@ -490,7 +490,7 @@
> if self.decodeStatePoller:isRunning() then
> self.decodeStatePoller:stop()
> end
> - self.alarmInProgress = 'none'
> + self.alarmInProgress = nil
> self.alarmWindow = nil
> end
> )
> @@ -512,7 +512,7 @@
> end
> end
>
> - self.alarmInProgress = 'none'
> + self.alarmInProgress = nil
> self:_stopTimer()
> self.alarmWindow:playSound("WINDOWHIDE")
> self:_hideAlarmWindow()
>
--------------------
> >
>
> So basically, quit using the 'none' string and instead nil out
> self.alarmInProgress, and then check for self.alarmInProgress as well
> as audioState not equal to 1 for the hammer rearm. Make sense?
>
> FYI, tests look good so far with this patch
>
> #!/ben
Just something to be cognizant of here, Ben: The fundamental nature
of the sledgehammer function was originally twofold...
1) During a 'server' triggered alarm, to determine if the server
originated audio is still good (otherwise fire off the local fallback
audio).
2) During an 'rtc' triggered alarm (whether initially triggered
this way or previously 'server' triggered only to revert to 'rtc' due to
bad server stream), to attempt to wrestle back the local audio
subsystem/player from whatever is contending for it.
The modified sledgehammer logic now has fundamentally changed case 2
above. The sledgehammer will no longer attempt to wrestle back the
local audio subsystem/player unless the audio state (status.audioState)
is also bad. It *may* be that status.audioState will always show as bad
during this condition, but I'm not convinced that the contention will
necessarily parallel the audioState condition. With the current logic,
if the states do not occur in parallel there will be little debug
information to analyze for failure cases.
If it was indeed your intention to couple the two conditions ('rtc'
alarm in progress AND bad audioState) then I'd at least suggest the
following modification to facilitate debug output that would shed light
on any failure cases related to case 2 above.
Code:
--------------------
if self.alarmInProgress and status.audioState ~= 1 then
hammer = true
else
if self.alarmInProgress
log:warn('alarm_sledgehammerRearm: `', self.alarmInProgress,'` alarm
outstanding and audioState is good')
end
end
--------------------
This way, if there is a failure case that involves case 2 (which I
suspect there may be in the future), there will at least be log output
showing that the 'rtc' alarm was in progress while the audio state was
good (even as the local audio stopped playing)...
Marc
--
Marc
------------------------------------------------------------------------
Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776
View this thread: http://forums.slimdevices.com/showthread.php?t=74025
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta
