How to handle partial data loading.

[RamsayRomero]

I am having an issue where it appears only part of the audio data is loading for my audio elements. I call wavesurfer.load() with the url to an mp3, and call wavesurfer.getDuration() on the ready event. Sometimes, and usually only with my larger files, the duration would either be incorrect, or 0. Yet the audio player would be able to play the entire audio. Another related issue that would happen was that the audio would stop playing past a certain point, and would be unable to seek further. Refreshing the content would usually fix this.

In order to determine whether or not wavesurfer was the issue, I replaced my wavesurfer code with just bare html audio elements, and the same issue would occur intermittently. The value for the duration of the track just wouldn't be visible sometimes, yet the audio would continue to play, or would fail to play past a certain point and would be unable to seek. When these issues happened with both the wavesurfer and implementations, I would see this error in the console: net::ERR_CONTENT_DECODING_FAILED 206 (Partial Content)

It seems like the browser only loads partial data for the file and is unable to fetch the remaining data. Does anyone know why this might be happening and is there anything I can do on the server or client to fix this? And if there is nothing I can do to reliably make this issue go away, is there something like an event I can listen to to determine that the content was not fully loaded, so I can show a proper indication in my UI, rather than an incorrect duration value?

[katspaugh]

You should check the events the audio element has: https://developer.mozilla.org/en-US/docs/Web/API/HTMLAudioElement/Audio

loadedmetadata should fire after the duration is known. Perhaps there’s also an error event that you could listen to.

wavesurfer.getMediaElement() will give you an internal audio element.

I can’t say much about http servers in this regard. Perhaps try different ones? I would expect mainstream solutions like S3/CloudFront to work well out of the box.

[RamsayRomero]

Thanks for the reply. The issue seems to be described here. In short, it seems like this is just the browser's default behavior when loading audio via http, sometimes it cannot calculate the duration. Especially for larger files. If I throttle the network I can reproduce this issue almost every time.

As far as a workaround, I'm not really sure. The loadedmetadata and other events such as canplaythrough still fire when this happens, and no error related events happen. The only thing I could think of is to add duration metadata beforehand or to change the ui in some way. Atm my UI is showing the duration as Infinity:NaN since I'm trying to divide by 0 when formatting the duration.

And as far as the server goes, we're just using Google Cloud Storage out of the box so I'm not sure there's much we could do there.

If you or anyone else has experienced this before or has any ideas for some workarounds, that would be greatly appreciated.

[katspaugh]

Are you using v7 btw? The duration is guaranteed to be there in v7 because it falls back to the decoded data duration if the media element doesn't have one.

[katspaugh]

If the duration is detected but is incorrect, try subscribing to the durationchange event maybe? I'm not sure if it will work. If it does, I'll include it into the library.

[RamsayRomero]

Just tried with v7 and this issue goes away 👍

Regarding your second suggestion, the HTML audio element wouldn't return a duration that is incorrect, it would just return Infinity until the audio had played through. So I don't think subscribing to the durationchange event would help in v7 since the decoded duration is already there. Using wavesurfer v6.2.0, it would return a duration that was not correct. Usually a bit shorter than the actual duration.