Is this using Web Audio or <audio>?

It is an <audio> element.

I updated the code to both console.log the element and make it accessible via "window.wavesurferAudioElement".

I think this is due to the file being served as 200 OK versus 206 OK. You should serve the file from a server which supports range-requests, for data savings reasons caching is restricted sometimes on Android versus Desktop; when this happens seeks can't be performed since the server can't send us just the chunk for the seek time.

This might have something to do with the problem, but:

1) The server _is_ sending a portion of the audio, and not the entire audio.
2) It was working fine until a few days ago. Beta not working, regular working. Something got broken, and it's not my code...

Unless I am missing something here, this issue just got a _lot_ more critical!!!!

I just noticed that my Chrome Canary on Windows was similarly affected (maybe as of a day ago?) and had the same problem.

But then I updated Canary to 73.0.3636.2, AND IT DOES NOT PLAY THE AUDIO AT ALL.

It looks like the problem is that in these new versions 71+ onwards: my server (Cloudflare!!!) sends a response that it accepts ranges, but Chrome throws out the response!!!

My current regular Chrome build (71.0.3578.80) is also now affected!!!

After adding "Header set Accept-Ranges bytes" explicitly into my .htaccess file, this seems to fix matters. I can't tell if it's a Cloudflare issue or a Chrome issue, although I don't know why there would be a difference that I noticed between regular Chrome Android and beta if it's not a Chrome issue.

I will continue to debug this issue in a more controlled environment later this week.

Caching behavior may change. We do allow seeks in cases where the entire file fits in our preload window since we can remove the server from the equation, this has never worked for larger/longer files though.

If adding it to your server fixes the issue it shouldn't be cloudflare injecting such support. They may just clone what you offer. If you see the issue with your server properly configured, then we will see about escalating with cloudflare folks.

It just does not seem like explicitly setting this header (which Cloudflare clones) should be necessary. Will debug further...

Marking as WontFix pending updates from reporter.