Can't re-play audio file from Mercurial repositiory in Chrome

Question

In my HTML5 test file, I can play and re-play an mp3 sound file just fine if:

1. My files are hosted locally, OR
2. They are hosted on a traditional web host (see http://sgdk2.enigmadream.com/ben/iotaBuildIt/sound.html) OR
3. I play it from Internet Explorer

I can play the sound the first time, but cannot play it a second time if:

1. The files are hosted in a Mercurial repository AND
2. I am using Chrome to access the file

(I don't have the problem when using IE to access the Mercurial-hosted files.)

Under these conditions, I can't RE-play the file either when:

1. Accessing it via an HTML page (http://hg.code.sf.net/u/bluemonkmn/myiota/raw-file/97ac02a717fe/HTML/sound.html) a. I can't make script replay it AND b. I can't use the audio control UI to replay it. NOR
2. Directly accessing the file (http://hg.code.sf.net/u/bluemonkmn/myiota/raw-file/97ac02a717fe/HTML/bing.mp3)

Can someone explain or help me fix it so Chrome can re-play the audio files hosted in Mercurial as IE does? Also, I have not tested FireFox, and would be interested to hear how it works there.

Answer 1

I have reported Chromium bug #129165 with the suspicion that this is a bug since it apparently works under works Linux.

Answer 2

If I had to guess I'd say the difference lies in the headers that Apache static file serving and hgweb provide. Here's the output for the .mp3 file from Apache's static file serving:

$ HEAD -Ssed http://sgdk2.enigmadream.com/ben/iotaBuildIt/bing.mp3
HEAD http://sgdk2.enigmadream.com/ben/iotaBuildIt/bing.mp3
200 OK
Connection: close
Date: Wed, 23 May 2012 16:55:03 GMT
Accept-Ranges: bytes
ETag: "4d0cbbe-16c7-4bd83a906c040"
Server: Apache
Content-Length: 5831
Content-Type: audio/mpeg
Last-Modified: Thu, 12 Apr 2012 23:24:41 GMT

and here it is coming from hgweb's raw-files handler:

HEAD http://hg.code.sf.net/u/bluemonkmn/myiota/raw-file/97ac02a717fe/HTML/bing.mp3
200 Script output follows
Connection: close
Date: Wed, 23 May 2012 16:56:33 GMT
Server: Apache/2.2.3 (CentOS)
Content-Length: 5831
Content-Type: audio/mpeg
Content-Disposition: inline; filename="bing.mp3"

The big differences are that Apache includes an Accept-Ranges header and hgweb provides a Content-Disposition header.

The Content-Disposition header here only suggests to your browser a default file name for saveAs, so it's not likely the culprit (but one never knows).

The Accept-Ranges header is more interesting. While not it's original purpose it's become the backbone of seeking in streaming audio and video playback. If one thinks of play again as just a special case of seeking (seek to zero), then maybe Chrome is disabling that because without the Accept-Ranges header it doesn't think it can seek at all (though, of course seeking to zero is just playing from zero again).

That's definitely just spit-balling, but it would be easy enough to test. Tweak your hgweb's apache host to use mod_headers like this:

header add Accept-Ranges bytes

in the path that's running your hgweb (be it wsgi or cgi). While you're at it you can remove the Content-Disposition header with mod_headers too.

In the end it's all about the bytes on the wire. You can make hgweb and Apache return the exact same bytes and then Chrome will handle it the same.

Note: It's, of course, the case that adding the Accept-Ranges: bytes header to hgweb's output doesn't actually add byte range support to hgweb, but that's okay. hgweb will just ignore the Range: bytes=xxxx header and instead of giving the 206 Partial Response status it will give a 200 OK and the RFC says that the client (Chrome) is required to deal with it. So you'll not be able to skip around in the files, but it just might be enough for Chrome to let you seek-to-start / replay.