click on waveform restart track using chrome

[icyz]

live test example: http://www.fasys.it/prestashop/index.php?id_product=2&controller=product click on "Test 2" in the description.

this is my wavesurfer's configuration: var options = { container : document.querySelector('#waveform'), waveColor : 'grey', progressColor : '#F39C11', cursorColor : '#222', cursorWidth : 3, height : 30, backend : 'MediaElement', //using WebAudio works (need to start track before it's fully loaded) };

waveform version 1.0.30 (tried with 1.0.29, 1.0.28 etc) chrome version: 44.0.2403.107 m on windows 8.1 . works well on FF and IE.

any suggestion? thanks

[katspaugh]

Have you solved it?

[icyz]

I'm investigating... I found that if I load media like this: wavesurfer.load('http://localhost/prestashop/index.php?controller=attachment&id_attachment=10'); this returns the problem

the same file loaded using: wavesurfer.load('http://localhost/prestashop/testmedia.mp3'); this works well

ideas?

[katspaugh]

Probably a problem with your web server, content-type or range requests. For mp3 browser understands that it's an mp3, for attachment=10, not.

[icyz]

I don't know if this is a bug or not but using Safari when i trying to load media without extension (eg: test) returns me "Error loading media element" (using backend "media element"). The same with mp3 extension (test.mp3) it works.

[edwardsmarkf]

wavesurfer is totally awesome. i understand that chrome cannot create a waveform on-the-fly using opus files.

is there an html5 feature i can test for this ability using Modernizr? i am tempted to just test the browser but using Modernizer would probably be much better.

UPDATE: i am looking at Modernizr now. can anybody think of a specific test that would determine if a browser is capable of creating a waveform for Opus? i really dont want to use "userAgent" if can help it.

[earwick]

i'm currently experiencing this issue, however there's an odd twist to it. i'm working on an app that allows you to upload music and play it back with a wavesurfer player. one of the tracks that i've uploaded is allowing click to seek just fine, however, any new files i upload to my app and attempt to click to seek on results in a restart of the playback. the odd bit is that this one file is allowing proper seeking, consistently. i've even reuploaded that specific file and the new copy has the restart problem. this is in chrome.

in firefox it all seems to work just fine.

i am using a very rudimentary python webserver, however, that doesn't seem to be the problem as it's working in firefox and in one instance on chrome. i thought it might be a problem with the actual mp3, but the fact that with two identical files one is working and one isn't seems to rule out that possibility. any other ideas?

edit: after some toying with some things a bit further it appears to be exclusive to 'mediaelement' backend. it's working fine on 'webaudio', however, i would prefer to use mediaelement. i'm wondering if it's potentially something related to the size of the files? it seems that it happens to longer/larger mp3s more frequently.

[lorenzfischer]

Hi, I had the same problem and resolved it by sending the correct headers from the backend. I use the PlayFramework in the back, so here's my Scala code*:

 def getAudioFile(id: String): Action[AnyContent] = deadbolt.SubjectPresent()() { implicit request =>
    repo.loadFileById(id).map {
      _ match {
        case Some(bais: ByteArrayInputStream) =>
          val source: Source[ByteString, _] = StreamConverters.fromInputStream(() => bais)
          val contentLength: Long = bais.available().toLong
          Result(
            header = ResponseHeader(200, Map(
              CONNECTION -> "keep-alive",
              ACCEPT_RANGES -> "bytes",
              CONTENT_LENGTH -> contentLength.toString,
              CONTENT_DISPOSITION -> s"attachment; filename=${id}.mp3"
            )),
            body = HttpEntity.Streamed(source, Some(contentLength), Some("audio/mpeg3"))
          )
        case None =>
          NotFound(s"No record found with ID $id")
      }
    }
  }

In case you wonder what the values for these constants are:

val CONNECTION = "Connection"
val ACCEPT_RANGES = "Accept-Ranges"
val CONTENT_LENGTH = "Content-Length"
val CONTENT_DISPOSITION = "Content-Disposition"

*) I found the correct headers on this thread of the PlayFramework mailing list.

[vatologic]

It seems Chrome still isn't playing nice with MediaElement as a backend. I'm using a script that caches an audio file into an IndexedDB blob; seeking resets in Chrome, works fine in FireFox and Safari. Only workaround is to sniff the browser and make Chrome use WebAudio as backend, which is a pity since I kind of need that MediaElement to use other audio related plugins.

Update: Since I had things cached anyway, I could set the MIME type to 'audio/mpeg' on the blob - now Chrome is working fine. It seems Chrome really needs the correct MIME in order to seek.

// assuming myBlob is already a blob with audio/mpeg data inside // (ab)use slice() to force a MIME/type myBlob = myBlob.slice(0, myBlob.size, 'audio/mpeg');

[parsagholipour]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Configuring_servers_for_Ogg_media Added this header Accept-Ranges: bytes and now it works in chrome properly

[universalhandle]

I think it's the combination of Accept-Ranges: bytes and Content-Length: x (where x is the file size in bytes). In my case it works only if both are present. Below are the headers in my now-working implementation. (Note: many of these are added automatically by the Koa node.js framework I'm using. I've only explicitly added the two mentioned above.)

HTTP/1.1 200 OK
Vary: Accept-Encoding, Origin
Access-Control-Allow-Origin: *
Content-Type: application/octet-stream
Accept-Ranges: bytes
Content-Length: 11768748
Date: Tue, 29 Dec 2020 17:33:17 GMT
Connection: keep-alive

[universalhandle]

It may be worth noting that mp3s were behaving as expected in Chrome until I started serving some which were produced using ffmpeg's concat protocol. Those files required the aforementioned two headers to behave correctly.