question

jm001 avatar image
jm001 asked

audioplayer and offsetinmilliseconds

Has something changed very recently regarding AudioPlayer and offsetInMilliseconds. ?

I have some long(ish) mp3s (say, for example ,16 mins) and my skill keeps track of how far the user has got to, and effectively resumes play from where they left off

This has always worked nicely.

But now, if the offset > approx 9 mins, it causes the playback to fail with a result of

"Player error occurred: Player has been buffering for at least 30 seconds"

I am sure this isn't a slow download/timeout problem ; what superficially *appears* to happen is that it now takes so long to try to seek forward 9 mins that the 30 sec timeout is kicking in and killing playback. If I then manually reset the offset to 0, it immediately successfully plays the file ...

alexa skills kit
10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

jm001 avatar image
jm001 answered

This point is unrelated to the root problem above, but another observed change is that "PlaybackNearlyFinished" used to fire nice and early to allow the echo time to get the next enqueued file to minimise inter-track gaps; this happening long before "playback finished" fired.

Now, the 2 are almost coincident. And this introduces more of a gap between tracks/files. On a slow dsl link, it must be very noticeable.....

10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

jm001 avatar image
jm001 answered

Just to put this into context: it now appears to take AudioPlayer 29 seconds (of real time) to seek forward 400 seconds within the mp3. This is a substantial (and very detrimental) change .....

10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

jm001 avatar image
jm001 answered

This is very easy to reproduce btw

Take an MP3 of length say 30 mins

Play it with a AudioPlayer.Play (playBehavior: "REPLACE_ALL" ), with an offset of say 580000

Observe the timeout occurring.

Also, imho, the change in behaviour of "PlaybackNearlyFinished", as detailed above, is quite detrimental to the user experience ....

10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

jm001 avatar image
jm001 answered

I think this is related .... Since the changes, I wish I could second guess the logic between the (new?) usage of the HEAD requests and the subsequent GET requests, as employed by AudioPlayer when actually fetching the file, or m3u, to play.

I thought I understood how these are used normally, but what I am seeing in my server logs makes no sense to me at all :(

Some comments from those in the know regarding the general point would help here .....

10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Brian@Amazon avatar image
Brian@Amazon answered

Looking into this. Is there anything specific about the server logs which you do not understand at all?

1 comment
10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Is there any update of this? I am getting the same issues as decribed by @jm001, it takes over 30s to seek forward in the audio when there is a large offset.

Surely the AudioPlayer should just request the bytes starting at the offset provided? If you play audio in Chrome it uses the Range header to request the segment of the audio it requires, meaning the client doesn't need to decode the entire audio file before seeking to the part it requires. I haven't seen the AudioPlayer make any range requests even though my server accepts them.

Thanks,

Ed

0 Likes 0 ·
tti@germany avatar image
tti@germany answered

Same effect here in this scenario (bigger mp3, offset of a few minutes): Server logs of the audio source are showing a HEAD Request followed by a GET Request of the whole file and 30 seconds later a Timeout-Response in my Skill appears - playback never starts...

But only my Echo Dot behaves like this. My normal big Echo using the same Skill / File / OffsetInMilliseconds does instantly resume the playback on the desired position. Here the server logs of the audio source are displaying an (for me expected) Range-Request, which the server answers with a Partial Response. I will append the original server logs in a few hours here...

Btw.: I only have the Echo Dot since a few days ... so dunno, how the audio player of the Echo Dot behaved in the past. But my normal Echo never showed such a problem. But please fix this....

@jm001: The HEAD request is for receiving only the headers of a resource, without fetching the resource (body = audio file in our case) itself. So a client can verify, if a resource exists, without receiving it in the first place and - more important - what features the server would accept for a particular resource. Like - if the server supports Range-Requests of this resource or for receiving caching-hints like the ETag or just the content-length itself etc...

2 comments
10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

What are you returning in the HEAD request? We are aware of an issue where if the HEAD request hangs/doesn't reply, the 30s delay occurs, and then the GET request is finally issued. We're aiming for parity but right now the Echo Dot and Echo have some minor differences in behavior.

0 Likes 0 ·

It's an standard nginx server (ubuntu 17.10 artful [in September, it was an 16.10]) answering as described in RFC 7231 Section 4.3.2:

The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at
the end of the header section).
# nginx -v
nginx version: nginx/1.12.1 (Ubuntu)

At least with the files I'm testing, all nginx responses HEAD|GET are identical as expected and described above. Timeframe between first byte of request received by nginx and last byte of response send by nginx is around 5 to 15 ms. Alexa and nginx are in the same network, so the router won't even route the Alexa-GET/HEAD requests of the audio source throu my ISP, since the public ip the of the domain is already the public ip of the router...

0 Likes 0 ·
tti@germany avatar image
tti@germany answered

Well, nothing special in the headers:

Request headers of the working GET-Request by Echo

[Range] => bytes=10519416-
[Icy-Metadata] => 1
[Accept] => */*
[Host] => some-host-name

Request headers of the non-working HEAD/GET pair by Echo Dot

//HEAD
[Host] => some-host-name
[Connection] => close
[Icy-Metadata] => 1
[Accept-Encoding] => identity
[User-Agent] => the original url to the stream

//GET
[Connection] => Keep-Alive
[Host] => some-host-name
[Icy-Metadata] => 1
[Accept-Encoding] => identity
[User-Agent] => AlexaMediaPlayer/5.1.1-272.5.8.8_user_588443520 (Linux;Android 5.1.1) ExoPlayerLib/1.5.9

Server logs

# by Echo
ip some-host-name "-" [26/Sep/2017:18:22:47 +0200] "GET /some-mp3-resource HTTP/1.1" 206 10810899 OK 4.456 174

# by Echo Dot
ip some-host-name "-" [26/Sep/2017:18:24:15 +0200] "HEAD /some-mp3-resource HTTP/1.1" 200 350 OK 0.010 301
ip some-host-name "-" [26/Sep/2017:18:24:54 +0200] "GET /some-mp3-resource HTTP/1.1" 200 16891904  39.368 290

# log format at the end:
# $status $bytes_sent $request_completion=OK $request_time $request_length
10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Jonathan avatar image
Jonathan answered

For anyone else having this issue, looks like Amazon have FINALLY noticed and responded in the other thread related to this https://forums.developer.amazon.com/questions/86765/resume-doesnt-work-if-mp3-file-is-large.html?sort=newest

10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

tti@germany avatar image
tti@germany answered

Next (maybe related) issue with the Echo Dot audio player.

Playback (without offset) of one particular mp3 file results in:

[error] => Array

                (

                    [message] => Player error occurred: com.google.android.exoplayer.ParserException: Searched too many bytes.

                    [type] => MEDIA_ERROR_INTERNAL_DEVICE_ERROR

                )

Mediainfo

Format                                   : MPEG Audio
File size                                : 21.5 MiB
Duration                                 : 54 min
Overall bit rate mode                    : Constant
Overall bit rate                         : 56.0 kb/s
Genre                                    : Vocal


Audio
Format                                   : MPEG Audio
Format version                           : Version 2
Format profile                           : Layer 3
Mode                                     : Joint stereo
Mode extension                           : Intensity Stereo + MS Stereo
Channel(s)                               : 2 channels
Sampling rate                            : 22.05 kHz
Compression mode                         : Lossy
Stream size                              : 21.5 MiB (100%)

Same file plays without trouble on my Echo ...

Is there any reasonable explanation, why my Echo Dot has an other audio player as the Echo? It's fine for me as long as they both would work ... but - at least in some edge cases - this is definetely not the case...

Gosh, I'm so happy, that I only need this for a private-usage-only skill and not for some sort of business model since this kind of black-hole-issue-reporting is sort of improvable...

2 comments
10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Nothing about that information would indicate the audio is incompatible, knowing the exact source of the audio file would help us narrow this down. We have deployed some fixes for some discrepancies between playing audio on first-get echos and other devices, but there still isn't complete parity.

0 Likes 0 ·

Can't provide the original audio file - it's an meeting protocol under NDA. But the audio file is sort-of broken: it's real playback time doesn't match the media length according to the mediainfo headers (its 5 mins shorter). But I'm sure, due to the "Searched too many bytes"-ParserException, this was already clear? Dunno how the heck this happend in the first place or how I could reproduce an file with such an error; but on the other hand I never found an audio player which had any trouble with it yet. And for me it's fine, if non-broken files would play with an given offset.

Is there any overview available, which model uses which audioplayer? Do the new models use an audioplayer, which supports playback-with-an-larger-offset already (as my Echo does)? Since - for me - this is getting a bit frustrating, since the main reason for an 2nd echo dot was to play such meeting protocols in my bedroom ... and seeking is essentional for that purpose. But since the original report of the "offset"-bug is now nearly 3 months old and we haven't heard much since then ... I'm at the point: If I can fix my problem by buying a new 100 bucks Echo...

0 Likes 0 ·
Jonathan avatar image
Jonathan answered

This is really starting to become a major issue, and I'm really hoping to get an update on this. Much of the long-form audio I serve is over an hour and, in testing, this is really killing the functionality of my skill.

I have now boiled the audio down to the very minimum size/quality, and also changed it from VBR to CBR in case that might help, but still takes about 10 seconds to seek per 4 minutes of audio when returning.

Format                                   : MPEG 
AudioFile size                           : 38.2 MiB
Duration                                 : 1 h 23 min
Overall bit rate mode                    : Constant
Overall bit rate                         : 64.0 kb/s

Incidentally, in case it matters, these are the user-agent headers I see hitting the file:

`AlexaMediaPlayer/5.1.1-272.5.9.7_user_597465220 (Linux;Android 5.1.1) ExoPlayerLib/1.5.9`

I can confirm that the server definitely correctly responds to byte-range requests and is serving the correct MIME type. A download remote download speed test from my audio server shows a sustained 85Mb/sec, so it's not that end of things.

It might be that I have poor internet connection here where the dot is of about 5Mb/sec, however, that should matter as it shouldn't be seeking through like that, it should be requesting a byte range offset.

Any update from @Jenn@amazon or @Brian@Amazon would be welcome as it's been 6 months since first reported. Thanks

10 |3000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.