Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users
Status: Fixed
Owner:
Closed: Mar 2
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment
HTML5 Audio is broken when loaded from cache
Reported by phobos...@gmail.com, Dec 30 2016 Back to list
Chrome Version       : 55.0.2883.95 (Official Build) (64-bit)
URLs (if applicable) : http://phoboslab.org/files/html5audio/chrome-cache-bug.html
Other browsers tested:
     Safari: ok
    Firefox: ok
         IE: -

What steps will reproduce the problem?
(1) Visit http://phoboslab.org/files/html5audio/chrome-cache-bug.html
(2) Reload the page
(3) Check the "Last Event" for the 3rd Audio Element - if it's `canplaythrough`, go to step 2. If it's `loadedmetadata` proceed to 4.
(4) Attempt to play the 3rd Audio Element

What is the expected result?
Audio should play. `play`, `timeupdate` and `ended` events should fire.

What happens instead?
Audio does not play. The `waiting` event is fired instead.


 
Comment 1 by a...@chromium.org, Jan 4 2017
Labels: Needs-Triage-M55
Cc: brajkumar@chromium.org
Components: Blink>Media>Audio
Labels: -Type-Bug -Needs-Triage-M55 M-56 OS-Mac Type-Bug-Regression
Owner: xing...@intel.com
Status: Assigned
Able to reproduce this issue on Mac OS 10.12 using chrome latest stable M55-55.0.2883.95 by following steps mentioned in the original comment. By clicking on the play button of 3rd audio element the 'waiting' even is fired.

Bisect Information:
--------------------------
Good build: 55.0.2871.0
Bad build:    55.0.2873.0

Change Log: https://chromium.googlesource.com/chromium/src/+log/55.0.2871.0..55.0.2875.0?pretty=fuller&n=10000

Unable to invoke bad builds during python tool bisect, so providing manual bisect information. As per the above log observing only one change which is related to Html5, Hence assigning to the same.
Review-Url: https://codereview.chromium.org/2355743005

xing.xu@ Do you have any idea on this bug? Incase of this issue is not related to your change please feel free to reassign to the concerned dev person.

Thanks! 
Comment 3 by xing...@intel.com, Jan 4 2017
Patch https://codereview.chromium.org/2355743005 is about dialog, nothing to do with audio.  And http://phoboslab.org/files/html5audio/chrome-cache-bug.html didn't use dialog. So how about someone audio related check this first?
This bug appears to be fixed on the Canary version (57.0.2977.0), but not the beta version (56.0.2924.51).
Comment 5 by roy...@google.com, Jan 13 2017
Labels: Hotlist-Enterprise
Cc: xing...@intel.com maxkirsch@chromium.org royans@chromium.org
Labels: -Pri-3 Pri-1
Owner: dgreid@chromium.org
Hey dgreid@, are you the right person to look into this, or do you know who is?

I'm upgrading this bug to P1 because it's currently impacting standardized testing on CrOS and we're already receiving user reports.
Comment 7 by dgreid@chromium.org, Jan 14 2017
Owner: maxkir...@google.com
Way too far up the stack for me if it is happening on Mac as well.
Comment 8 by cyrusm@chromium.org, Jan 14 2017
Cc: cyrusm@chromium.org
Owner: dalecur...@chromium.org
Hey dalecurtis@, would you be the right person to take a look at this, or do you know who is?
Same problem here.. Broken on 55.0.2883.95, works well on Canary 58.0.2990.0.
Cc: dalecur...@chromium.org
Labels: Needs-Bisect
Owner: hubbe@chromium.org
This site makes 12 connections for the audio files, this exceeds the max of 6 connections for an HTTP connection. This is probably issue 58467, +hubbe in case there's anything interesting from a network perspective that we could be doing better here.

If you have assets like this you should mark the tags as preload=none, or preload=metadata to cycle down the connections. preload=auto expects that playback will begin shortly.

Seems like another bisect should be done too.
Cc: w...@chromium.org rbasuvula@chromium.org
Labels: -Needs-Bisect hasbisect-per-revision
Tested in chrome stable #55.0.2883.95 on Mac 10.12.2 and able to reproduce the issue. Not able to reproduce the issue in beta #56.0.2924.67 dev #57.0.2986.0 and canary #58.0.2991.0. So providing the reverse bisect details.

Bisect Info:
------------
Good Build: 56.0.2910.0 (Revision- 430103)
Bad Build: 56.0.2909.0 (Revision- 429737)

You are probably looking for a change made after 430085 (known good), but no later than 430086 (first known bad).

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/c48a68ee1b819983e6849dbccadf33b7248db8c1..d026f79cc5949df6bae399f58128b470f8061ad7

From the CL above, assigning the issue to the concern owner. Probably this change could have fixed the issue.

@ watk : Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change.

Review-Url:  https://codereview.chromium.org/2445533002
Cc: sande...@chromium.org
Looks like this might be fixed by Dan's recent changes. I'd expect latest M57 to work then though.
Comment 14 by w...@chromium.org, Jan 24 2017
sandersd@ and I took a look at this. This is what appears to be happening:

* We add players in the idle state initially
* RendererWebMediaPlayerDelegate performs an idle player cleanup after 8 players are added
* So sometimes this third player is idle suspended because the cleanup runs almost immediately after it's created before loading has ever progressed (last_time_loading_progressed_.is_null()). The logic it uses to accept the suspend request is:
  if (last_time_loading_progressed_.is_null() ||
        (tick_clock_->NowTicks() - last_time_loading_progressed_) >
         kLoadingToIdleTimeout)
* That should be fine, though, because the next time didLoadingProgress is called we'll resume the player.

So our hypothesis is that didLoadingProgress() is not called. This code relies on the invariant: after load() is called, if any reads succeed then didLoadingProgress will be called at least once. Looks like this isn't happening in this case. 

If you open the devtools network tab you can see different network behavior in the cases where it works and doesn't work. When it works as expected you can see network requests for the media files (beep*.ogg) (whether they're satisfied by the disk cache or not doesn't matter). When it doesn't work there are zero requests for the media files (but they're still loading from somewhere). I don't understand the latter mode. hubbe@? 
Comment 15 by aurel...@gmail.com, Jan 25 2017
Some observations:
1. the bug cannot be reproduced inside an iframe. The last event will always be `canplaythrough`.
2. also, the bug cannot be reproduced on the `file://` protocol.
2. the devtools network tab not showing the ogg files should be treated as a separate bug. It most certainly **is** a bug, but it's not directly related to the current one.
Status: Fixed
Unable to reproduce this on ToT. Seems very likely that Dan's changes fixed it.

Sign in to add a comment