This is expected to happen when there's an unknown duration or if decoding doesn't reach the specified duration. Can you explain why you expect it to remain the same?

??!!!??

Try it on every other browser.

The duration should stay the same because the duration is exactly 1875.957551 seconds. It should not be any bigger than this!

Try changing it to" Media.currentTime = media.duration * .99" or "Media.currentTime = media.duration * 1" also.

When given an invalid file there's no guarantees on the behavior. As a best effort we update to whatever was possible to decode.

I don't think you understand me.

1) Invalid file? It is not an invalid file...???

2) You have it backwards... "whatever was possible to decode" means you start with a smaller size and get to the true size, but the true size is 1875.957551 seconds. It goes to a bigger value than this instead which is 1876.188996 seconds. It should not go to 1876.188996 seconds!!!

3) How do you explain the fact that the result is different between setting currentTime to .9999 of the value and 1.000 of the value?

4) Behavior shouldn't be different across browsers. canplay is called after setting the currentTime.........

Unless it truly is an "invalid [corrupt] file", I guess, which I don't think it is -- seems fine to me (created with Audacity).

Sorry, I misunderstood, you tagged the bug with "(This could be a security risk (i.e.: buffer overflow), perhaps.)". But after looking at it again this isn't an invalid file it's just untagged VBR mp3 which by necessity has a variable duration (since unless we decode the whole file we can't know the true duration). This is similar to  issue 419974  and  776663 .

Either way this is still WontFix per the previous bugs. Adding appropriate tagging with the duration information fixes the issue and improves playback performance (we don't need to scan 1mb+ [max ffmpeg scan size] looking for a non-existing duration tag anymore):

$ ffmpeg -i duration_haywire.mp3 -acodec copy fixed_duration.mp3

Ah, thanks.

But, Chrome is running this estimate only if the currentTime is set to near-1, but not 1, and Chrome runs multiple canplay events when currentTime changes. Is this what it's supposed to do? Neither Edge nor Firefox do this.

If you let the whole file play out and be cached before seeking, the seeking duration will be correct afterwards. The estimate is just an artifact of not having enough information to determine the duration. We enable fast seek in these files too, so we seek based on estimated position. Otherwise we'd have to load quite a bit of data which is painful on a slow connection.

canplay is supposed to fire on "readyState newly increased to HAVE_FUTURE_DATA or greater." seeks set the readyState to have_metadata, unlike other events on the spec, "canplay" doesn't have "for the first time." So the chrome behavior is per spec. I can't comment on what the intent there is though.

https://html.spec.whatwg.org/multipage/media.html#event-media-canplay

I suspect in Edge and Firefox in a fresh profile on a slow connection playback will take quite some time to start.

Ok, got it. Thanks for your help on this.