Resume doesn't work if MP3 file is large

Question

Hi,

Some of our users use our skills to play some large mp3 files but they have trouble resuming their audio if they pause towards the end. They have raised a support ticket with us and on our side we get below error returned from Alexa:

{ "message":"Player error occurred: Player has been buffering for at least 30 seconds", "type":"MEDIA_ERROR_INTERNAL_DEVICE_ERROR" }

Answer 1

Answer by Jenn@amazon · Sep 26, 2017 at 10:41 PM

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

4 Show 3 · Share

Jonathan · Oct 03, 2017 at 10:15 AM 0

Share

Any updates? Thanks

Aaron Manela · Dec 08, 2017 at 03:52 PM 0

Share

Is there any news on this question/bug?

NewUser-72dbf54d-7d64-4da9-a18b-675d5e7ee2bd · Dec 25, 2017 at 07:45 PM 1

Share

Hi, could you please provide a ticket number or something, this issue is still reproducing. I do understand you probably don't consider this as a major issue but there are people here trying to use your platform and build apps and a 'small' issues like this which takes months to be addressed does create a bad image in the face of dev comunity... Thank you.

Answer 2

Answer by Danny · Nov 17, 2017 at 05:31 AM

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

If start playback of "LargeAudioFile" and then stop it and play it again, everything works fine.
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.
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.

2 Show 1 · Share

tti@germany · Jan 09 at 07:29 PM 0

Share

Thanks for pointing out nr. 3; it's really working that way and allowed me to - at least - implement a horrible-but-working temporary hack for this problem in my skill.

Brain.dump:

1) If offset is to high to resume on the device, send a "Play @ Offset 0" with an outputSpeak, explaining, that amazon is ignoring this bug for 4 month (and counting) and, to resume, the user must manually invoke the Intent again. Remember some "resume hack flag" per deviceId in this case for a short time.

2) On Audioplayer.PlaybackStarted Event, response with an Stop directive, if the "resume hack flag" is set for the deviceId (no sessionid exists here). Alexa won't play a tone in this case, but loads the stream. Yay.

3) On Audioplayer.PlaybackStopped, well - don't persist the given offset, when the "resume hack flag" is set.

4) If the user repeats the last command, and the "resume hack flag" is still active, resume at the desired offset and everything is working. On the next Audiopalyer.PlaybackStopped/Finished, remove the "resume hack flag" from the cache.

Horrible. Horrible. Horrible. But working...

Plz, plz, plz ... I'm begging you. Plz... fix this bug. It's getting ridiculous...

Answer 3

Answer by AlexaDj · Dec 03, 2017 at 04:34 PM

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

2 · Share

Answer 4

Answer by jm001 · Aug 30, 2017 at 09:06 PM

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

1 · Share

Answer 5

Answer by AnyPod · Sep 08, 2017 at 02:51 AM

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?

1 · Share

Answer 6

Answer by jm001 · Sep 09, 2017 at 06:46 AM

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 :(

1 · Share

Answer 7

Answer by Starfish Mint · Sep 13, 2017 at 01:52 AM

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

1 · Share

Answer 8

Answer by jm001 · Sep 13, 2017 at 10:10 AM

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 ...

1 Show 3 · Share

jm001 · Sep 14, 2017 at 05:15 PM 1

Share

Actually, I have a good idea. Can I humbly suggest to Amazon that they introduce a new Forum Badge ? There is a Japanese horror film called "Ringu", which was re-made as a US film called "The Ring". Basically, the plot is anyone who watches a certain film (well, video) comes to a very sticky end (it's quite a scary film btw - don't watch it just because you read this ...). Now, this has certain similarities to this problem/thread. I am sure some Amazon employee must want to reply to this thread (???), but must feel doing so might be a career ending move ? (I say this because for the life of me I cannot fathom the deafening silence on this point) So .... introduce a "Ringu" forum badge for posts that are factually correct, but cannot be answered for internal reasons ..... Or .... please tell us we are being stupid and correct us in the error of our ways .... or ..... anything ?

{bump}

Starfish Mint jm001 · Sep 14, 2017 at 08:32 PM 0

Share

lol. I guess let it go is the answer :-)

jm001 Starfish Mint · Sep 15, 2017 at 09:00 AM 0

Share

Methinks you are right. Think I need some of that hair restore cream that keeps getting spammed here coz I have pulled out what is left of my hair :( Sadly, I do admit defeat, though ....

Answer 9

Answer by NewUser-51e9809b-1d70-43b4-b6ab-d88b2fca9a4a · Nov 29, 2017 at 07:07 PM

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?

1 · Share

Answer 10

Answer by jm001 · Sep 03, 2017 at 08:16 AM

I would sincerely appreciate an answer to this point from Amazon, as I am at a loss how to work around this apparent change in functionality....

0 · Share

Resume doesn't work if MP3 file is large

15 Replies

Follow this Question

Related Questions