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 215 users
Status: Fixed
Owner:
User never visited
Closed: Nov 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
Byte range cache is locked when attempting to open the same video twice
Project Member Reported by scherkus@chromium.org, Dec 22 2009 Back to list
Try and load the same video on the same page from two different <video>
elements.  You'll notice they never load.  Attempting to refresh the page
will display the status text "Waiting for cache..." and the page refuses to
load.

This can also be reproduced by having the same video opened (Open video in
new tab) twice.  One tab may start playing while the next tab has to wait.

Does not happen with --disable-byte-range-support
 
double_video.html
231 bytes View Download
That makes sense... The cache has a single writer-multiple readers logic so while the 
video is being downloaded any attempt to read will be queued.
That's what I thought was going on...  I'm guessing the writer lock on the entire
resource and not a section of the resource?

Correct. Currently the state is per transaction (request) so we cannot have two 
transactions modifying the resource.
Labels: -Mstone-5 Mstone-X
Labels: -Area-Internals -Internals-Video Area-WebKit Feature-Media
Comment 6 by hclam@chromium.org, Jan 20 2011
Labels: HelpWanted
Status: Available
This bug need a new owner, assigning to scherkus by default.
Comment 7 by mal@google.com, Feb 14 2011
Labels: -HelpWanted GoodFirstBug
Labels: -GoodFirstBug bulkmove Hotlist-GoodFirstBug
Try and load the same video on the same page from two different &lt;video&gt;
elements.  You'll notice they never load.  Attempting to refresh the page
will display the status text &quot;Waiting for cache...&quot; and the page refuses to
load.

This can also be reproduced by having the same video opened (Open video in
new tab) twice.  One tab may start playing while the next tab has to wait.

Does not happen with --disable-byte-range-support
Cc: acolwell@chromium.org alberto@chromium.org karen@chromium.org hclam@chromium.org *sjl@chromium.org fischman@chromium.org ddorwin@chromium.org ajwong@chromium.org annacc@chromium.org vrk@chromium.org
Issue 82855 has been merged into this issue.
Cc: -*sjl@chromium.org
Labels: -bulkmove
Labels: -Mstone-X
Owner: ----
scherkus: do you know why this happens for ogv files but not webm files?
Cc: yihongg@chromium.org
 Issue 101960  has been merged into this issue.
Labels: Mstone-18
We will look into this soon.
 Issue 68056  has been merged into this issue.
Labels: -Feature-Media -Hotlist-GoodFirstBug Feature-Media-Cache
Labels: -Internals-Network
Owner: fischman@chromium.org
Status: Assigned
 Issue 106780  has been merged into this issue.
This is happening in YouTube right now (trying to open the same video in different tabs).

 Issue 79484  has been merged into this issue.
 Issue 108153  has been merged into this issue.
 Issue 110494  has been merged into this issue.
 Issue 111394  has been merged into this issue.
Labels: -Mstone-18 Mstone-19
Definitely not getting done for m18.  In talks about priorities to see if it'll make m19.
 Issue 115736  has been merged into this issue.
Cc: imasaki@chromium.org alek...@chromium.org
 Issue 116670  has been merged into this issue.
Labels: -Mstone-19
Removing Mstone label since it's not being worked on.
 Issue 122557  has been merged into this issue.
 Issue 131527  has been merged into this issue.
Comment 32 by sh...@chromium.org, Aug 30 2012
 Issue 145834  has been merged into this issue.
 Issue 146497  has been merged into this issue.
 Issue 146792  has been merged into this issue.
 Issue 136529  has been merged into this issue.
 Issue 150912  has been merged into this issue.
Does happen with --disable-byte-range-support.
Tested : 
http://jsfiddle.net/kyCy3/1/
Google Chrome	21.0.1180.81 (Official Build 151980)
OS	Linux
Cc: ligim...@chromium.org rponnada@chromium.org kerz@chromium.org
 Issue 151026  has been merged into this issue.
not working also on dev channel 24.0.1305.3 dev-m:

http://jsfiddle.net/KbVY8/11/

Behaviour is that first video starts playing, and subsequenct videos are shown only when the first video has finished downloading.

also happens with --disable-byte-range-support
Owner: ----
Status: Available
Cc: -alek...@chromium.org
Cc: -imasaki@chromium.org
Labels: -Feature-Media-Cache Feature-Media-Network
 Issue 168810  has been merged into this issue.
Cc: srsridhar@chromium.org
 Issue 170055  has been merged into this issue.
 Issue 180006  has been merged into this issue.
Happens for WebM and Ogg for me. Somebody mentioned that it happens with HTML5 video in YouTube different tabs.

Project Member Comment 48 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-WebKit -Feature-Media-Network Cr-Content Cr-Internals-Media-Network
 Issue 173787  has been merged into this issue.
 Issue 222562  has been merged into this issue.
 Issue 223355  has been merged into this issue.
Project Member Comment 52 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
 Issue 323532  has been merged into this issue.
Cc: davidben@chromium.org
 Issue 323943  has been merged into this issue.
Labels: Cr-Internals-Network-Cache
 Issue 326593  has been merged into this issue.
Is there any hope for fixing this anytime soon?  Just look at all the duplicate requests that have been merged into this one since it was opened more than three years ago.  I'd love to recommend that my users use my video player in Chrome, but this issue is a big caveat.

My major use case is F4V (Flash-wrapped MP4) files.

I requested reconsidering the fix of this bug and what I believe is his blocking bug https://code.google.com/p/chromium/issues/detail?id=46104, which seem to have a positive response in comment 16 there.
Is google chrome under maintenance mode? A real 3 years + bug is happening. Does this bug require to bend the laws of physics to get it fixed? At the end of the day, this browser is just software and a bug of this type should never last 3 years under any circumstance.
Is google chrome under maintenance mode? A real 3 years + bug is happening. Does this bug require to bend the laws of physics to get it fixed? At the end of the day, this browser is just software and a bug of this type should never last 3 years under any circumstance.
Owner: fischman@chromium.org
Status: Assigned
fischman@ could you please look into this issue?

Thanks in advance.
Owner: ----
Status: Available
Nothing's changed in this arena for a while AFAIK.  When I looked into it a couple of years ago the bug was being caused by fundamental design choices in the disk cache system and I failed to come up with a solution that didn't radically change that system.  This bug's priority was deemed too low at the time to justify such work, and so it has remained undone.  
I find it rather sad that this has a low priority with this many people stumbling across the bug. It's not possible to look at two different positions in a html5 video (including YouTube) in two different tabs of Chrome. It's not possible to include the same video in two different video elements on the same page at two different time offsets (e.g. to make a list of interesting scenes).I regard this as a quite severe bug.

What does it take to encourage somebody to attack that disk cache system bug? I'm happy to offer a beer or two (or sparking wine)!
My current solution is to insert a random string after the sources, Chromium does not have a problem with that (test page: https://dl.dropboxusercontent.com/u/6833781/videojs-test/index_sameVideoSources.html )...
 Issue 255068  has been merged into this issue.
 Issue 266335  has been merged into this issue.
 Issue 171480  has been merged into this issue.
 Issue 327612  has been merged into this issue.
Comment 69 Deleted
Comment 70 by Deleted ...@, Apr 1 2014
Chrome, dudes, you really need to fix this. This is such an epic fail for HTML5, especially after Google has harped on about HTML5 media for so long.

For such an obvious bug to persist for all these years, Chrome devs must be cherry-picking easy/trendy cards to work from.
Labels: Restrict-AddIssueComment-Contributer
 Issue 347161  has been merged into this issue.
Comment 73 by k...@google.com, Apr 10 2014
Labels: -Restrict-AddIssueComment-Contributer Restrict-AddIssueComment-Commit
Owner: rileya@chromium.org
Status: Assigned
Taking a stab at this: https://codereview.chromium.org/232003002/
 Issue 362295  has been merged into this issue.
 Issue 369295  has been merged into this issue.
Cc: tkonch...@chromium.org
 Issue 377214  has been merged into this issue.
 Issue 377768  has been merged into this issue.
 Issue 386319  has been merged into this issue.
Cc: japhet@chromium.org anandc@chromium.org
 Issue 234779  has been merged into this issue.
Project Member Comment 81 by bugdroid1@chromium.org, Aug 26 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fa29c3e30198fcdb462ec65f0627a5e5f524effb

commit fa29c3e30198fcdb462ec65f0627a5e5f524effb
Author: dalecurtis <dalecurtis@chromium.org>
Date: Tue Aug 26 23:40:59 2014

Bypass http cache for concurrent range requests.

Take over of https://codereview.chromium.org/232003002/, which
instead utilizes the seemingly new cache timeout logic.

All partial requests which hit net::ERR_IO_PENDING will now be
immediately timed out.

BUG= 31014 
TEST=layout tests, net_unittests, new unittest, manual.

Review URL: https://codereview.chromium.org/478763004

Cr-Commit-Position: refs/heads/master@{#292031}

[modify] https://chromium.googlesource.com/chromium/src.git/+/fa29c3e30198fcdb462ec65f0627a5e5f524effb/net/http/http_cache_transaction.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/fa29c3e30198fcdb462ec65f0627a5e5f524effb/net/http/http_cache_unittest.cc

Cc: -fischman@chromium.org
 Issue 234779  has been merged into this issue.
 Issue 416300  has been merged into this issue.
 Issue 433534  has been merged into this issue.
Labels: M-39
Status: Fixed
The user visible aspects of this issue are fixed by http://crrev.com/fa29c3e3 and will be available in M39; which will ship to stable in the next couple weeks.  Issue 58467 tracks a more efficient fix to this problem and I have plans for improved media caching in future Chrome releases.
Sign in to add a comment