-
Notifications
You must be signed in to change notification settings - Fork 605
Focus manager issue on AVS #138
Comments
I see the same issue : ( happens when trying to play my playlist from amazon music back to back. ) Speaking...########################### |
Any comments on this ? Your help is highly appreciated . I don't see this issue with iHeartRadio , wondering what could be different SDK wise. |
Hi simplistiq and shikha-bansal, Looking at the code that logs
It is waiting for AudioPlayer::executeOnFocusChanged(FOREGROUND) to return. The code for that logs "executeOnFocusChanged" upon entry. However, that does not show up in the log provided. So, it seems likely that AudioPlayer::m_executor is blocked handling some previously submitted task. With more complete logs it might be possible to look further back and find out what is holding things up. Would it be possible to get more complete logs? Also note that It is very possible that playing non iHeartRadio content is simply failing and leaving the AudioPlayer or underlying MediaPlayer in a broken state. Thank you for bringing this issue to our attention, |
These are the logs as generated with DEBUG9 option. Is there a MACRO I can enable to get more logs. |
shikha-bansal, Yes, I can see you have DEBUG9 logging enabled - and that is super helpful! What I was asking for are logs that go further back in time to see if we can identify a previous AudioPlayer operation that is blocking the AudioPlayer::m_executor's thread. Thank you, |
Here are more complete logs : Listening...############################ Thinking...########################### Alexa is currently idle!######################################## Speaking...########################### Alexa is currently idle!######################################## |
We see lock issues in AudioPlayer. We are testing the AudioPlayer by issuing next/previous/thumbs up/thumbs down commands by interrupting the system. AudioPlayer blocks acquiring lock in the following line void AudioPlayer::onPlaybackFinished() { 2017-09-06 09:48:22.548 [ 39] 9 AudioPlayer:onPlaybackFinished try acquire lock |
Thanks for the analysis , when can I expect to get a fix for this. |
I get the same issue when trying to read a book from Audible. I get the response "starting your book " , but then Audioplayer is stuck. 2017-09-12 21:16:35.421 [ a] 0 AudioInputProcessor:setState:from=IDLE,to=RECOGNIZING Listening...############################ Thinking...########################### Speaking...########################### Alexa is currently idle!######################################## |
Thank you all for the useful logs. I've been able to reproduce focus management issues in AudioPlayer. We will be digging into this as soon as possible to provide a potential fix. |
any updates on this one ? |
is this issue supposed to be fixed with 1.0.3 ? |
Hi shikha-bansal, The issue is not fixed in 1.0.3. I was able to reproduce your issue and I think I may have found a fix. The problem lies in the AudioPlayer making a call to releaseChannel and then never calling acquireChannel before playback starts. You can try adding a check for if the FocusState is None in executeOnPlaybackStarted() and if it checks out making a call to acquireChannel |
Hi, We are also still experiencing that issue on SDK V1.0.3.
Can you please evaluate the fix below where we are changing code above to request to acquire Channel only if Focus state is equal to NONE. That will avoid ask for require a channel while in BACKGROUND and
Thank you in advanced |
Hi julianobRibeiro, After some introspection, the fix I originally suggested turned out to be a bit misguided. We don't want to make an additional call to acquireChannel at all, because the releaseChannel call that is screwing everything up should never have been made. As a temporary fix, try saving the m_currentActivity to a temporary variable before the switch statement in executePlay, and then adding an |
- Changes in this update: - Better GStreamer error reporting. MediaPlayer used to only report `MEDIA_ERROR_UNKNOWN`, now reports more specific errors as defined in `ErrorType.h`. - Codebase has been formatted for easier reading. - `DirectiveRouter::removeDirectiveHandler()` signature changed and now returns a bool indicating if given handler should be successfully removed or not. - Cleanup of raw and shared pointers in the creation of `Transport` objects. - `HTTP2Stream`s now have IDs assigned as they are acquired as opposed to created, making associated logs easier to interpret. - `AlertsCapabilityAgent` has been refactored. - Alert management has been factored out into an `AlertScheduler` class. - Creation of Reminder (implements Alert) class. - Added new capability agent for `PlaybackController` with unit tests. - Added Settings interface with unit tests. - Return type of `getOffsetInMilliseconds()` changed from `int64_t` to `std::chronology::milliseconds`. - Added `AudioPlayer` unit tests. - Added teardown for all Integration tests except Alerts. - Implemented PlaylistParser. - Bug fixes: - AIP getting stuck in `LISTENING` or `THINKING` and refusing user input on network outage. - SampleApp crashing if running for 5 minutes after network disconnect. - Issue where on repeated user barge-ins, `AudioPlayer` would not pause. Specifically, the third attempt to “Play iHeartRadio” would not result in currently-playing music pausing. - Utterances being ignored after particularly long TTS. - GStreamer errors cropping up on SampleApp exit as a result of accessing the pipeline before it’s been setup. - Crashing when playing one URL after another. - Buffer overrun in Alerts Renderer. - [SampleApp crashing when issuing "Alexa skip" command with iHeartRadio.](#153) - [`HTTP2Transport` network thread triggering a join on itself.](#127) - [`HTTP2Stream` request handling truncating exception messages.](#67) - [`AudioPlayer` was attempting an incorrect state transition from `STOPPED` to `PLAYING` through a `playbackResumed`.](#138)
This issue is fixed in release v1.1.0. Thanks! |
In the latest 1.0.2 SDK, we are seeing that on a multiple next/previous scenario when playing Amazon prime music, the FocusManager sometimes loses focus. The Play directive is received however AudioManager never gets the Focus to play out the url. It happens if we do the iterations back-to-back without having to finish out playing the current song. Although this SDK may not support prime per release notes, this lock on Focus Manager may be a generic problem.
Logs are below:
2017-09-01 20:03:10.967 [ 5] 0 HTTP2Stream:receivedRequestId:value=x-amzn-requestid: 0af853fffed7bf42-00003b0c-00006de2-05e16d7adfd4a2b0-0773c98b-267
2017-09-01 20:03:10.982 [ 6] I DirectiveSequencer:onDirective:directive={"namespace:"SpeechSynthesizer",name:"Speak",messageId:"bd2ff320-8440-4cd5-b9f0-521931d6856c",dialogRequestId:"83e62f21-c076-4ac2-af50-ec448e512a0c"}
2017-09-01 20:03:10.982 [ d] I DirectiveRouter:preHandleDirective:messageId=bd2ff320-8440-4cd5-b9f0-521931d6856c,action=calling
2017-09-01 20:03:10.982 [ d] 0 CapabilityAgent:addingMessageIdToMap:messageId=bd2ff320-8440-4cd5-b9f0-521931d6856c
2017-09-01 20:03:10.982 [ d] 9 SpeechSynthesizer:preHandleDirective:messageId=bd2ff320-8440-4cd5-b9f0-521931d6856c
2017-09-01 20:03:10.982 [ 9] 0 SpeechSynthesizer:executePreHandle:messageId=bd2ff320-8440-4cd5-b9f0-521931d6856c
2017-09-01 20:03:10.983 [ e] I DirectiveRouter:handleDirective:messageId=bd2ff320-8440-4cd5-b9f0-521931d6856c,action=calling
2017-09-01 20:03:10.983 [ e] 9 SpeechSynthesizer:handleDirective:messageId=bd2ff320-8440-4cd5-b9f0-521931d6856c
2017-09-01 20:03:10.982 [ b] 0 DialogUXStateAggregator:DialogUXStateAggregator::receive() - THINKING == m_currentState
2017-09-01 20:03:10.984 [ 9] 0 SpeechSynthesizer:executeHandle:messageId=bd2ff320-8440-4cd5-b9f0-521931d6856c
2017-09-01 20:03:10.984 [ 9] 9 SpeechSynthesizer:addToDirectiveQueue:queueSize=1
2017-09-01 20:03:11.184 [ 3b] 0 DialogUXStateAggregator:transitionFromThinkingTimedOut()
2017-09-01 20:03:11.184 [ b] 0 DialogUXStateAggregator:transitionFromThinkingTimedOut - moving to IDLE
2017-09-01 20:03:11.184 [ b] 0 DialogUXStateAggregator:setState:from=THINKING,to=IDLE
2017-09-01 20:03:11.185 [ a] 0 AudioInputProcessor:setState:from=BUSY,to=IDLE
########################################
Alexa is currently idle!
########################################
UIManager::onDialogUXStateChanged state = IDLE
InteractionManager::onDialogUXStateChanged to IDLE
######## QcomSoundTrigger::stopRecording() 1
AudioManager::StopRecorder() 0
2017-09-01 20:03:11.185 [ c] 0 QCMediaPlayer:QCMediaPlayer::restoreVolume - :restore Volume = =1
2017-09-01 20:03:11.186 [ f] 9 AudioPlayer:onFocusChanged:newFocus=FOREGROUND
2017-09-01 20:03:11.186 [ a] 0 AudioInputProcessor:executeOnFocusChanged:newFocus=NONE
2017-09-01 20:03:11.186 [ a] 0 AudioInputProcessor:executeOnFocusChanged:reason=Lost focus
2017-09-01 20:03:11.187 [ c] 0 QCMediaPlayer:QCMediaPlayer::restoreVolume - :restore Volume = =1
2017-09-01 20:03:13.186 [ f] E AudioPlayer:onFocusChangedFailed:reason=timedout,cause=executorTimeout
The text was updated successfully, but these errors were encountered: