-
Notifications
You must be signed in to change notification settings - Fork 603
Sometimes sample app gets stuck in "Speaking" mode forever #189
Comments
Hi @Sergogr , are you running on Raspberry Pi Or Linux or MacOS? Also in your log, it looks like you were using MediaPlayer. Does this happen in normal questions to Alexa? Like 'Whats up?', 'What's the weather outside?' |
can you put a log in DialogUXStateAggregator.cpp in transitionFromSpeakingFinished(), to check if it actually calls that function after Speaking State? |
Hi @mradulan, I am running on Raspberry Pi. This happens in normal questions to Alexa. I will add the log in transitionFromSpeakingFinished() later, and let you know. |
Hi @mradulan I added the log and I see that transitionFromSpeakingFinished() is not getting called when the issue happens. BTW, it seems that asking "Alexa what's up" and then "Alexa what is the time" repeatedly makes it easier to reproduce (~30% chance). |
Hi @Sergogr , can you put a log in MediaPlayer.cpp in sendPlaybackFinished function and in SpeechSynthesizer in onPlaybackFinished to check if it gets called? |
@mradulan Please look carefully at the log that I attached in the very first message. It is clear from that log that both of those functions were called. Here is the excerpt: 2017-09-25 18:13:35.292 [ 2] 0 MediaPlayer:callingOnPlaybackFinished <--- this is from sendPlaybackFinished 2017-09-25 18:13:35.293 [ 2] 9 MediaPlayer:tearDownPipeline |
for some reason the onDialogUXStateChanged is not getting called i.e the DialogUXStateAggregator is not being notified. |
I am assuming that you hear some speech in SPEAKING state and then it gets stuck. Can you put a log in onStateChanged(SpeechSynthesizerObserver::SpeechSynthesizerState state) in DialogUXStateAggregator.cpp to see if it reached the state SpeechSynthesizerObserver::SpeechSynthesizerState::FINISHED |
I have a similar problem. I put in some logging in onStateChanged and I see it hits the FINISHED case and proceeds just like the other times. The one thing I see is in the broken trace doStopSuccess is delayed by something. Below is the snippets between doStop->sendPlaybackFinished broken trace as follows: |
At least for me, after more investigation, transitionFromSpeakingFinished is never called from m_multiturnSpeakingToListeningTimer. Which is the same issue @Sergogr has found and I'm using SDK 1.1.0. This is being caused by m_multiturnSpeakingToListeningTimer lapsing so the timer's task never gets called. What's the correct way to fix this? I'm sure there is a reason why we aren't calling the task when the timer expires but without it we get stuck. |
Hi @Sergogr, @ryan-esty, Please try adding 'm_stopping = false;' at this point in Timer.h. It should resolve the issue. Ken |
That code was already there but I still get stuck. The only way that I can get out is if I put a call to task() before the return while it is waiting to stop or the time elapsed. Ryan |
Ok. As you suspected in your previous comment, adding a call to task() before the return is not correct for the Timer class - we only get into that code block if the timer has been asked to stop, and stopping should not implicitly cause the task to execute out of schedule. A correct fix for this would need to happen in the code which is asking the timer to stop; if the calling code wants the timer task executed when stopping, it should call it directly rather than expecting the timer to do it during the stop call. I've reviewed the code in DialogUXStateAggregator.cpp related to the m_multiturnSpeakingToListeningTimer. The timer's task is to change state to IDLE when the timer expires. The only place the timer is stopped prematurely is during a setState() call, when the state is being intentionally changed away from FINISHED. Unfortunately, I've been unable to reproduce the issue you are seeing with some simple/repeated multiturn testing. Can you outline the specific steps you are following that lead to this stuck state? Ken |
@kencecka If I take out the call to task() all I do is ask alexa for a series of questions with a single response. After a couple of iterations I will notice I get stuck in the speaking state. In our current design we no longer care if it gets stuck in speaking as we don't have a KWD but have to do something external to listen for the next question. I attached the last bit of the log on the last listen transition. I said Hi when we first connected and what time it is next. On the second interaction it was stuck in speaking and never came out. |
Changes in this update * **Enhancements**.. * Added comments to `AlexaClientSDKConfig.json`. These descriptions provide additional guidance for what is expected for each field... * Enabled pause and resume controls for Pandora... * **Bug Fixes**.. * Bug fix for [issue #329](#329) - `HTTP2Transport` instances no longer leak when `SERVER_SIDE * Bug fix for [issue #189](#189) - Fixed a race condition in the `Timer` class that sometimes * Bug fix for a race condition that caused `SpeechSynthesizer` to ignore subsequent `Speak` directives... * Bug fix for corrupted mime attachments.
All, I finally upgraded to 1.2.1 and I have yet to see the stuck in speaking issue as I was seeing. It only took a couple of tries on our platform to get in this state. I hope it if fixed for the rest in this thread. Ryan |
Did this fix your issue? Ryan |
Closing due to inactivity. Please reopen if you're still encountering this issue in our latest release @Sergogr. Thanks, |
Changes in this update * **Enhancements**.. * Added comments to `AlexaClientSDKConfig.json`. These descriptions provide additional guidance for what is expected for each field... * Enabled pause and resume controls for Pandora... * **Bug Fixes**.. * Bug fix for [issue #329](alexa/avs-device-sdk#329) - `HTTP2Transport` instances no longer leak when `SERVER_SIDE * Bug fix for [issue #189](alexa/avs-device-sdk#189) - Fixed a race condition in the `Timer` class that sometimes * Bug fix for a race condition that caused `SpeechSynthesizer` to ignore subsequent `Speak` directives... * Bug fix for corrupted mime attachments.
Changes in this update * **Enhancements**.. * Added comments to `AlexaClientSDKConfig.json`. These descriptions provide additional guidance for what is expected for each field... * Enabled pause and resume controls for Pandora... * **Bug Fixes**.. * Bug fix for [issue #329](alexa/avs-device-sdk#329) - `HTTP2Transport` instances no longer leak when `SERVER_SIDE * Bug fix for [issue #189](alexa/avs-device-sdk#189) - Fixed a race condition in the `Timer` class that sometimes * Bug fix for a race condition that caused `SpeechSynthesizer` to ignore subsequent `Speak` directives... * Bug fix for corrupted mime attachments.
I updated my SDK to the latest version (1.0.3), and found a new issue.
Sometimes (roughly 1 out of 10) sample app gets stuck in "speaking" state forever. Issue happens during regular question-answer interaction (no music/barge-in).
Debug log is attached. Please note, the log is not truncated, there was actually no call to DialogUXStateAggregator:setState
speaking_forever.txt
The text was updated successfully, but these errors were encountered: