i can repro this locally on linux.  will take a  look.

it has something to do with having the same video playing in multiple tabs.  for example:

- open http://vjs.zencdn.net/v/oceans.mp4 in a new tab, it plays
- open a new tab, go to http://vjs.zencdn.net/v/oceans.mp4 again.  it doesn't play.
- pausing the first tab does nothing.  closing it lets tab #2 proceed.

if one does nothing, then it will proceed after ~30sec by itself, per initial repro steps.

starting multiple tabs will behave similarly -- one will play. closing it will start the next one, etc.  don't know what happens after 30sec.

Interesting. The second tab is not even getting a chrome://media-internals entry, which likely means it's blocking before we even create the WebMediaPlayerImpl.

my repro was on 60.0.3112.32 with the steps in c#1.

seems to be in the multibuffer code somewhere.  in particular, we never get a progress callback => WMPI download callback => do actual work.

i'm running with some high-tech tracing machinery instantiated* to see what's up.

* i added printfs.

Setting appropriate labels until we understand this more. Even if it's just videos with the same URL, this can impact sites that use a background video, or even having things like gfycat open in multiple tabs.

Ah, I take back my statement in c#2 and agree with c#4, it's stopping sometime after WMPI creation. I think the version I tested didn't have the new WMPI creation logs that are on ToT now.

hubbe and i had an offline chat about it.  TL;DR: could believably be either multibuffer or the network cache.  going to see if it's sharing a multibuffer between attempts, and how many network connections they're opening.

the second reader is seeing zero available bytes initially, and waiting until some arrive.  if it's the same multibuffer, then that's broken.  if it's a different multibuffer, then it's (hopefully) creating a new network connection.  the question would be why there's no data arriving on it.

Potential culprits:
https://chromium.googlesource.com/chromium/src/+/54d4504bd6a17d6bb7a8628446b9e0ef5c3a74cf
https://chromium.googlesource.com/chromium/src/+/8061c420676998bda77caa74581ea8061860f438

+Internals>Network

I have verified that this bug is caused by https://chromium.googlesource.com/chromium/src/+/8061c420676998bda77caa74581ea8061860f438

Working on a fix. https://chromium.googlesource.com/chromium/src/+/8061c420676998bda77caa74581ea8061860f438 includes parallelization of headers phase of the 2 requests for the same URL. Earlier the second request would time out after 25ms (timeout for a range request) and go to the network but now its doing the headers phase in parallel with the 1st request's response body read phase but is waiting for the 1st request to complete before reading the response body. The fix should therefore add a timeout even after handling the headers phase. 

fix in progress in https://codereview.chromium.org/2953983003

shivanisha@, long-term question: When you complete the current refactor, that'll solve this issue without relying on the timeout, correct?

Answering rdsmith@'s question:
After the current refactor, all requests that are eligible for shared writing (non-range requests) will solve this issue without relying on the timeout but range requests , which the videojs.com example uses , will still rely on the timeout.

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

commit bc3b71b348b6073d188bb815443190ec73bf84a3
Author: shivanisha <shivanisha@chromium.org>
Date: Sat Jun 24 07:21:14 2017

Adds cache lock timeout handling after finishing headers phase.

Since now there is parallel validation of requests but the cache lock
still applies when the writer transaction is reading the response body
we need to have a lock timeout handling when a transaction is waiting
in the done_headers_queue as well.

This Cl also removes the unused RestartInfo structure definition.

BUG= 735998 

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

[modify] https://crrev.com/bc3b71b348b6073d188bb815443190ec73bf84a3/net/http/http_cache.cc
[modify] https://crrev.com/bc3b71b348b6073d188bb815443190ec73bf84a3/net/http/http_cache.h
[modify] https://crrev.com/bc3b71b348b6073d188bb815443190ec73bf84a3/net/http/http_cache_transaction.cc
[modify] https://crrev.com/bc3b71b348b6073d188bb815443190ec73bf84a3/net/http/http_cache_transaction.h
[modify] https://crrev.com/bc3b71b348b6073d188bb815443190ec73bf84a3/net/http/http_cache_unittest.cc
[modify] https://crrev.com/bc3b71b348b6073d188bb815443190ec73bf84a3/net/http/mock_http_cache.cc
[modify] https://crrev.com/bc3b71b348b6073d188bb815443190ec73bf84a3/net/http/mock_http_cache.h

[Auto-generated comment by a script] We noticed that this issue is targeted for M-60; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-60 label, otherwise remove Merge-TBD label. Thanks.

Removing M-60 and Merge-TBD labels since this issue was caused by  https://chromium.googlesource.com/chromium/src/+/8061c420676998bda77caa74581ea8061860f438 (refs/heads/master@{#479204}) while M-60 was branched at refs/heads/master@{#474934}. 

shivanisha@ I can reproduce the same issue on M60... Lets not drop the milestone information and such until that's accounted for.

Hmm, but can't repro today... Will keep testing and drop M-60 label if I can't repro.

Testing again; I still can't reproduce. I did hit issue 709302 during this test, so maybe that's what I saw before, but pretty sure the video was stuck at load on beta channel.

+Needs-TestConfirmation to see if they can reproduce the issue using the steps in c#1 on M-60.