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" }
Thanks for reporting this. We're looking into this and will update this thread with any news.
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.
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.
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...
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 ...
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}
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
Is this issue still occurring? An update was pushed recently that addressed a couple different playback back issues and I believe this is one of them.
12 People are following this question.
