791017 - Ogg Audio does not load from appcache after Firefox restart

Status: RESOLVED WONTFIX

(Core :: Networking: Cache, defect)

Description

[cscott]

http://nell-balloons.github.cscott.net contains a 2M ogg-format audio file which does not play when the site is used offline.  The site contains an appcache manifest which specifies http://nell-balloons.github.cscott.net/sounds/barrios_gavota.ogg as the source in an <audio> tag and normally when you select a level from the main screen this music begins playing and messages similar to the following are emitted on the javascript console:

[13:11:20.997] GET http://nell-balloons.github.cscott.net/sounds/barrios_gavota.ogg [HTTP/1.1 206 Partial Content 247ms]
[13:11:23.313] GET http://nell-balloons.github.cscott.net/sounds/barrios_gavota.ogg [HTTP/1.1 206 Partial Content 2595ms]

The request contains a Range: header, and the response contains a Content-Range: header.

Now, as far as I understand it, even this behavior is buggy: since the file is specified in the appcache manifest, it should be already cached and play from the cache; further partial requests to the origin server should not be required.

If you then disconnect from the internet and go to the same URL, almost everything works fine (since the application is cached) but this time the console messages are similar to:

[13:12:19.865] GET http://nell-balloons.github.cscott.net/sounds/barrios_gavota.ogg [undefined 0ms]

and the network request details reveal no status code and no response (as expected, since we're offline).  The audio does not play.

This occurs in FF 10 as well as the latest (2012-09-12) nightly of FF/Android (fennec) so this behavior has been around for a longish time.

Note that short sound effects seem to play fine from appcache.  There seems to be some logic which is bypassing the cache in favor of streaming for the longer track, which is the wrong thing for files stored in the appcache.

Comment 1

[cscott]

This bug may be related to the odd way in which clip duration must be computed for ogg files? (Bug 502894 comment 1).

Comment 2

[cscott]

I managed to workaround the issue by encoding the audio in webm format.  Different container, no longer needs to do the prescan for duration perhaps?  But I can't get the webm *video* to work now.  Plays first second or so and then stops.

The bug with ogg format audio needs to be fixed in any case.

Comment 3

[cscott]

Possibly related to bug 740045 ?  The fact that my videos won't play offline is currently a high-priority blocker for me.

Comment 4

[cscott]

I'm grouping the "ogg won't play from appcache" and "video won't play from appcache" bugs together for the moment, but they may turn out to be separate bugs.  For the record, I worked around my original "audio won't play" bug by switching from ogg audio to webm audio.  The webm container format apparently obviates the need to scan the audio file for duration, which was breaking on the appcache path.  The video bug is as described in bug 740045 comment 4 -- webm plays the first few frames and then stops.  I'm going to try the one-line source workaround in 740045 (tweaking nsBuiltinDecoder::NotifyDownloadEnded), fingers crossed.

Comment 5

[cscott]

I've renamed and focused this bug.  This is specifically for audio problems playing from appcache.  The linked url (http://mozbugs.github.cscott.net/791017/) contains three <audio> tags referencing files named in the appcache for the page.  Visit the page, select 'Allow' to allow it to store the files in appcache, and then wait for the download to complete (and the downloading message to go away). Now disconnect from the internet and visit the page again.

When offline the webm audio plays, and (if your platform supports it---for examples on Firefox/Android) the MP3 audio plays.  However the ogg audio only plays silence when offline.

(Note that the webm audio file uses the ogg codec, but the matroska container format.  So the problem is with the container format, which is (apparently) trying to grab bytes from the network to find the clip's duration even though the file ought to be served from appcache.)

Tested on Firefox 10 and Firefox Beta (16.0) on Linux as well as Firefox/Android Nightly (2012-09-15, 18.0a1).  This has been a bug for a while it seems.

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to cscott from comment #5)
> I've renamed and focused this bug.  This is specifically for audio problems
> playing from appcache.  The linked url
> (http://mozbugs.github.cscott.net/791017/) contains three <audio> tags
> referencing files named in the appcache for the page.  Visit the page,
> select 'Allow' to allow it to store the files in appcache, and then wait for
> the download to complete (and the downloading message to go away). Now
> disconnect from the internet and visit the page again.

I followed your STR here and the ogg files played properly when I re-visited the page with my network disabled. Can you retest and close this bug if the problem is now fixed? Thanks!

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

Ah, it seems the trick to reproducing this bug is to exit Firefox as well as disconnecting network.

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

Steps To Reproduce:

1. Load http://people.mozilla.org/~cpearce/app/
2. Wait for all audio on page to load.
3. Exit Firefox, including all windows in the particular Firefox instance.
4. Restart Firefox.
5. Load http://people.mozilla.org/~cpearce/app/
6. Observe that the Ogg audio file re-downloads, but the WebM file does not; the WebM file is retrieved from the appcache, whereas the Ogg file is not.

Expected Result:

* Ogg file should be loaded from app cache.

Does this need to block basecamp? Kilimanjaro? Seems like having cached Ogg's playable after restart is important.

Comment 9

[Andrew Overholt [:overholt]]

Since this isn't B2G-specific it doesn't seem like a basecamp blocker.

Honza, we thought you'd like to know about this.

Comment 10

[cscott]

Seems like this bug should be moved from UNCONFIRMED to NEW? cpearce confirmed it.