Resume doesn't work if MP3 file is large

Thanks for reporting this. We're looking into this and will update this thread with any news.

My skills are going super low in reviews because of this issue, it's already few months passed. Any updates, please?

I have the exact same problem using an Echo Dot. I just wanted to add a few extra details.

1. If start playback of "LargeAudioFile" and then stop it and play it again, everything works fine.
2. If start playback of "LargeAudioFile" and then play another audio file, like flash briefing or anything else, then go back to try to play "LargeAudioFile" with a big offset I get the "Player error occurred: Player has been buffering for at least 30 seconds" error.
3. If I repeat all of #2, but I try to play LargeAudioFile with a low or 0 offset, it starts to play. If I then stop the audio, manually adjust the offset back to being very large and tell it to play again it goes back to working fine.

I am getting the same "Player has been buffering for at least 30 seconds" today on an Echo Dot. Is there an update on the matter?

As we cannot get any guidance from Amazon, my guesswork is as follows:

2 weeks ago the audio player within my Dots changed from using an unknown library ("unknown" due to lack of user-agent) to

"AlexaMediaPlayer/5.1.1-272.5.8.4_user_ xxxx (Linux;Android 5.1.1) ExoPlayerLib/1.5.9"

This is not a guess - I can see this change in my server logs

This new audioplayer behaves quite differently, namely:

- It caches a lot now, and seemingly now uses HEAD requests to ascertain the presence of a cached file (which are surprisingly persistent - the Dot seems able to cache more that I would have thought, hence my previous comments above about request "strangeness")

- it sends a user-agent on GET requests to an actual mp3 file (but strangely on the HEAD requests, the user-agent is a repeat of the destination url ?, and this is also the case on a GET of an m3u playlist ??)

- compared to the previous library used, the new one does not like seeking MP3s. It is so slow at doing it now that the 30 sec timeout is kicking in - hence causing the underlying problem ...

[error] => Array

(

[message] => Player error occurred: Player has been buffering for at least 30 seconds

[type] => MEDIA_ERROR_INTERNAL_DEVICE_ERROR

)

- "PlaybackNearlyFinished" now fires just before "PlaybackFinished" (i.e. within the same second). It used to fire nice and early to give time for the Dot to get the next enqueued track (important for those on slow internet connections), however this is now not the case.

If you don't use the "offsetinmilliseconds" feature on mp3s, or the values you use are low in value, you probably won't have noticed any difference. If however, you do utilise the offset with say > 6 or 7 mins worth of value, it can/will break playback.

This post helps not, I know, as we need info from Amazon, not speculation and observation on my part. But, it will act as a post bump anyway ...

Wonder if it will catch someone in Amazon's eye if I add a explicit video to this post :-)

I am seeing strangeness with respect to HEAD and GET requests in the failure mode, yet am not sure its worth my time writing it up here if Amazon staff won't even respond to this point at all.

As we are now 11 days on from the initial reports (and 11 days on from a change to AudioPlayer here), I am surprised, and quite disappointed, at the complete lack of response from Amazon . This is not a good way to encourage an enthusiastic developer base :(

I haven't specifically isolated the playback offset to be related to this error but I am seeing A LOT more of this error in my usage logs. It seems like there needs to be more attention focused on this than there is - what's up Amazon? What, as far as Amazon's engineers are concerned, is to blame for this error?

I noticed that this seems to have been caused by a change to AudioPlayer at the end of last week.

https://forums.developer.amazon.com/questions/86577/audioplayer-and-offsetinmilliseconds.html

I was having a similar problem to the one that @Jonathan related in his Jan 08 '18 post, namely I was playing a large file (infinitely large, actually, as it was a radio stream), received user input that caused an interruption of that stream so that fixed length (about 8 minutes) alternate audio content could be played, and then desired a resumption of the original radio stream played in then real time. Effectively this equates to substituting fixed content for 8 minutes of the radio stream, which is the intent.

However, I was getting the same "Player error occurred: Player has been buffering for at least 30 seconds" error as @Jonathan. After looking at CloudWatch and Apache logs until I was blue in the face, it occurred to me that the error may be trying to tell me that the AlexaMediaPlayer might be trying to play but there's no device available to accept the data. As usual, immediately after receiving an AudioPlayer.PlaybackStarted request I would receive an AudioPlayer.PlaybackNearlyFinished request so I could queue up the next audio element. For the AudioPlayer.PlaybackNearlyFinished request received at the start of play for the 8 minute audio file, I was of course re-queueing the radio stream and noticed that there were then immediate HEAD and GET requests for that stream, yet there's nothing to play for 8 minutes. Could the AlexaMediaPlayer be buffering that partial content such that if more than 30 seconds passed before it could spit it out, I would get the error?

To test this, I grabbed a very small, short mp3 file of silence from http://duramecho.com/Misc/SilentCd/. When I received the AudioPlayer.PlaybackNearlyFinished request for the 8 minute audio file, I queued up the silence file rather than the radio stream. HEAD and GET requests were received for the small silence file which was then fully transmitted at that time. Eight minutes later, it was time to play the silence file, and of course there was no buffering error given that it was a short mp3 that was simply queued up to play like any other non-huge fixed length file. The start of play for the silence file brought about another AudioPlayer.PlaybackNearlyFinished request which was responded to by providing the URI for the original radio stream. While this caused immediate HEAD and GET requests on that stream, any buffering was only necessary until the short silence file played itself out, which took far less than 30 seconds. The radio stream then began to play live with no errors. Goal achieved.

Hopefully this helps someone who encounters this error in the future.