****Bulk Edit****

Setting as P1 for test team to prioritize in triaging.

+hubbe who is looking at a similar issue.

Does your videos have etags?

Yes, they are automatically generated by Amazon S3, and served by CloudFront; I don't believe that there is anything we can do to prevent them from being added, though they are consistently the same ETag on each subsequent response. I can provide a full HTTP conversation (with some data removed for security purposes) tomorrow if that helps?

I have created a basic test page which exhibits this issue, I will happily share a link to this privately if you need help reproducing this.

To follow up on this. I've been doing some more testing with video caching. In particular jumping to particular timecodes when content should be cached. Also resuming playing content following a pause. This behaviour seems to change in version 55 and 56. At this time my testing has been limited to OS X.

The following steps have different behaviour between version 54 and 55/56.
1. Load page with video player.
2. Play video
3. Pause video (note the download completes to the size of the video)
4. Play video, here 54 will play from cache, 55/56 will request the video again.

Similar happens if you jump playback to a part of the video, each jump will request the video again, and not use cache.

Hi,

I've found that disabling "Simple Cache for HTTP" in chrome://flags causes videos to cache properly, and subsequent pauses & scrubbing do not result in further downloads from the server.

Cheers,
David

Please note, with regards to my previous comment that this was the case for Chrome 53 on Linux, and did not behave the same in Chrome 56 on OS X 10.12.

Cheers,
David

Tested this scenario on windows 10 with both chrome versions #52.0.2743 and #58.0.3019.0 and observed the same behavior in both versions.

Test URL "http://video.webmfiles.org/big-buck-bunny_trailer.webm"

Observations:
================

1. As per this site "http://www.ghacks.net/2014/08/11/find-out-if-websites-get-loaded-from-cache-and-how-to-force-reloads/" if any loaded from cache, in the network tab -> size column it should display "from cache" which i didn't observe in both versions.

2.In both versions,  when i first time loaded the video in network tab -> type column it displayed 2 MB media file is downloaded and which will be not displayed in further reloads.

Attaching the screen-casts for reference.

Reporter@ could you please look into it and let us know your observations.

Deleted: Issue 689989-M52.mp4 5.0 MB

	Issue 689989-M52.mp4 5.0 MB View Download

Deleted: Issue 689989-M58.mp4 6.2 MB

	Issue 689989-M58.mp4 6.2 MB View Download

Hi,

I sent a reply via email, but I'm not sure where it went.


We agree that small videos do not exhibit this issue; however we can easily reproduce this issue with assets between 90MB & 1GB. I can send you a link privately to test with if this helps?

In addition, I would like to emphasise the impact of the pause issue that Steve has raised above; given that our staff & users are constantly pausing videos (on average ~300MB), their browsers are downloading the same video numerous times in the same browsing session causing our bandwidth charges to go through the roof.


Cheers,
David

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9974e4f50017f116c3696ce9cc38680e77ac14f1

commit 9974e4f50017f116c3696ce9cc38680e77ac14f1
Author: hubbe <hubbe@chromium.org>
Date: Thu Feb 23 01:14:29 2017

media: Stop sending if-match headers for media fetch requests.

Sending if-match headers disables caching, so stop doing that
until we can think of a better solution.

BUG= 689989 ,  504194 

Review-Url: https://codereview.chromium.org/2714583002
Cr-Commit-Position: refs/heads/master@{#452323}

[modify] https://crrev.com/9974e4f50017f116c3696ce9cc38680e77ac14f1/media/blink/resource_multibuffer_data_provider.cc
[modify] https://crrev.com/9974e4f50017f116c3696ce9cc38680e77ac14f1/media/blink/resource_multibuffer_data_provider_unittest.cc

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

If possible, could you please merge your change to M57 branch 2987 by 5:00 PM PT today, Friday (02/24) so we can pick it up for next week beta release.
Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8eab969d00c4919c3d969f89328826cd68ae310e

commit 8eab969d00c4919c3d969f89328826cd68ae310e
Author: Fredrik Hubinette <hubbe@google.com>
Date: Fri Feb 24 18:47:47 2017

media: Stop sending if-match headers for media fetch requests.

Sending if-match headers disables caching, so stop doing that
until we can think of a better solution.

BUG= 689989 ,  504194 

Review-Url: https://codereview.chromium.org/2714583002
Cr-Commit-Position: refs/heads/master@{#452323}
(cherry picked from commit 9974e4f50017f116c3696ce9cc38680e77ac14f1)

Review-Url: https://codereview.chromium.org/2710023009 .
Cr-Commit-Position: refs/branch-heads/2987@{#678}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/8eab969d00c4919c3d969f89328826cd68ae310e/media/blink/resource_multibuffer_data_provider.cc
[modify] https://crrev.com/8eab969d00c4919c3d969f89328826cd68ae310e/media/blink/resource_multibuffer_data_provider_unittest.cc

Verified this issue on Windows 10 with chrome beta #57.0.2987.88

These are the Observations
1. Loaded the video provided by user which about 80 - 90MB
2. For the first playing it has downloaded complete video file(observed in NetworkTab-> size column)
3. For Further repeating of video it has played from cache (observed in Networktab -> size coloumn)

Attaching a screencast for reference

hubbe@ could you please let us know this is expected behavior of this fix.

Thank You...

Deleted: Issue 689989.mp4 15.7 MB

Issue 689989.mp4 15.7 MB Download

This should be adequate verification I think.

 Issue 697112  has been merged into this issue.

Ticket Status says this is fixed. I can still see the issue in current stable versions  57.0.2987.74 beta (64-bit) and 56.0.2924.87. Please see my screenshots and working example in https://bugs.chromium.org/p/chromium/issues/detail?id=697112 Thanks for your help. 

The CL that caused the problem has been reverted and merged to M57 branch.
The versions you have, does not have the fix though. The first version that
has the fix is 57.0.2987.81. Please try again after next beta update.

As per comment #20, adding TE-verified labels

 Issue 683290  has been merged into this issue.

Hi,

I have just tested in Chrome 57.0.2987.88 beta (64-bit) on Ubuntu and I'm afraid the issue is still present.

After pausing the video after it has completely loaded, it re-downloads the rest of the video again and again. Please see attached screenshot.

Cheers,
David

Deleted: Selection_222.png 596 KB

	Selection_222.png 596 KB View Download

Hi,

We have reproduced this on both OS X and Windows using Chrome 57.0.2987.88 beta. We struggled at first and assumed everything was okay, as it appeared to load the video from cache on subsequent plays and scrubs; after a few minutes playing with the scrubbing bar, and hitting play/pause a few times we managed to download a 90M video several times.

Cheers,
David

I have not been able to reproduce this yet, do you have a test page that shows this behavior?

I'll PM you a sample video

Could you try going to "about:flags" and set "Simple Cache for HTTP" to Disabled and see if that makes the problem go away?

Hi,

Toggling this flag has no effect, I have just managed to fully download a video twice just by pausing and unpausing the video, there were a couple of "(from disk cache)" entries in the network log, but the majority were re-downloads.

Again using Chrome 57.0.2987.88 beta on both Linux & Windows, both exhibit this issue.

Cheers,
David

Hi,

I have managed to write a test page which reliably reproduces the issue, please find attached.

Cheers,
David

Deleted: index.html 3.8 KB

index.html 3.8 KB View Download

Nice test page.
When I run this on an M59 build, I get horrible performance if I use the
"simple HTTP cache". If I disable the "simple HTTP cache", about 95% of the requests come from the cache. (Not sure why it's not 100% though.)

I have another bug that I filed about the simple http cache.
I added this test page there, and added your name to the bug.
I'm not sure why disabling the simple http cache doesn't help for you though, so there might be more issues here...

Thanks Hubbe, does that mean this issue will remain "fixed"? Also, I don't think you added me to the CC on the other issue, you may have added the truncated, display version of my email address :)

Cheers,
David

Yes, as far as I am concerned, this particular issue is in regard to the if-match problem, which is solved. Other issues involving video caching deserve their own bugs. Discussing multiple issues in a single bug tends to cause confusion about what happens where and when. I apologize if I didn't add the right email address.
The new bug is:  crbug.com/700102 

Hi,

I have just tested Chrome 59 using the test video I supplied (though I have to hit play after the pause step and play the video through to the end in order to download it) - the original issue is still present. The browser is continuously downloading bits of the video and has transferred well over 2GB. Around 1 in 20 responses are labelled "from disk cache".

Cheers,
David

Hi,

Initially I could not reproduce this on a Microsoft Windows machine, then I scrubbed rapidly side-to-side (during step 4) until some requests were cancelled (coloured red in the Network tab), now Chrome consistently requests chunks of the video every scrub.

Cheers,
David

Hi,

I think this issue has resurfaced. Using the test page I provided I have now downloaded the video several times over.

Tested on Chrome 64, Ubuntu 17.10.

Cheers,
David

I think this is  crbug.com/700102 , which is not actually resolved yet.
Note that 700102 depends on how much disk space you have available, so it may come and go...

The machine I was testing this from had plenty of disk space available (43% free). None of the responses after the initial run through were cached at all; it smells strongly of this issue (as described initially). Please correct me if I’m wrong.

Cheers,
David


p.s. Replying to issues via email isn't working, I get an error telling me:

The email message you sent to chromium@monorail-prod.appspotmail.com
was not processed because it was not a reply to a notification
email that we sent specifically to <redacted>.

(The email address is correct, but it's rejecting it nonetheless)

43% of what though?
I think the current cache logic means that you need 257Gb of free disk space to allow this video to be completely cached.

43% free of 120GB. 257Gb free for a 250MB video file? Is that a typo?

No, it's not a typo I'm afraid.
Last I checked, the chrome "simple" cache tries to stay below 1% of the available disk space. (If there is a fair amount of disk space available.) It also has a limit that prevents any single entry from taking up more than 10% of the cache. Thus, to fully cache a 257Mb video, you need 257Gb of free disk space...