Tagging Blink>Media for triage.

ericmatthys@gmail.com, can you provide a repro url?

This bug is preventing Plex from being able to resume video playback after pausing for a while > 30 seconds.

Unfortunately, I don't have a public repro url. It is reproducible with Plex Media Server (https://www.plex.tv/downloads/) when transcoding video and music on the fly, which is why range requests are not supported.

Same problem here in Linux (with Chrome 51.0.2704.106), also using Plex Media Server. 

Same problem on version 51 on both my Linux and Windows machines

Doesn't seem to be Blink related. Leaving Internals > Media for triage.

I also see this behavior on my Toshiba Chromebook 2 2015, stable build 52.0.2743.116

I don't suppose there is a NAT server between your plex server and the browser?
NAT connections are usually closed after a period of inactivity, and when that happens, chrome cannot continue since it doesn't have the rest of the data.
If the range request succeeds even though the server says it doesn't support it, chrome can continue to play. If it does not, there is not a lot chrome can do.

I'll have to double-check this, but don't think chrome will close the connection when paused for a while, but once the connection is closed (for any reason), resuming playback is not really possible without range request support.

Same problem in Linux, Chrome 52.0.2743.116 (64-bit). No NAT between plex server and browser (home network). It came about half-year ago, after browser update. This problem don't allow view video in browser, so I use NFS now.

No NAT on my end either. Plex worked fine with Chrome 50. Definitely broke with a Chrome update.

Confirming that this bug still persists in 54.0.2840.16 beta-m (64-bit) on Windows 10.

My Plex server is running on a dedicated server hosted in a datacenter, no NAT or whatsoever.

hubbe@chromium.org or anyone else working on this bug. If you need access to a Plex server, email me your Plex username so I can share a library with you for testing purposes.
Alternatively send a friend request to "Jasdemi" on Plex. 

This seems to be related to suspending the pipeline. The timeout is 15 seconds and I noticed that if I pause until WebMediaPlayerImpl::OnSuspendRequested is called, then the video starts over from the beginning when I press play again.

I'm guessing that we should not suspend the pipeline of non-seekable videos?
Dale, can you comment on what the right behavior is, or perhaps hand this to someone who knows more about the suspending code?

To make it easier for the next person to reproduce, here is what I did:
I stuck a streamable file (wembly2.webm from our test matrix) in a directory
and ran "python -m SimpleHTTPServer 8888", then I ran a browser and pointed it to http://localhost:8888/wembly2.webm

Yeah, probably it's easiest not to suspend streaming sources; though we can't do this on Android, they must be suspended for things like fullscreen to work properly. Different behaviors are seen because we allow suspend/resume for software playbacks, but not hardware on desktop currently.

Really, this is not the right use of src= playback. Clients should be using a MSE based streaming solution instead. The HTML <video> specification does not provide any guarantees about how the browser will issue its network requests. The fact that it works at all is a happy (or not so happy) accident.

Over to sandersd@ to integrate this into the pipeline controller.

Chrome 54.0.2840.27 beta-m (64-bit)

Issue seems to be fixed. Playback will now resume even after a longer period of paused state (10min+). 

Thanks to everyone fixing this.

Hmm, we didn't fix what we thought was the issue here. When you have a stream and leave it paused can you check what's in chrome://media-internals to see if it is reported as "Suspended" ?

Couldn't find anything reported as "Suspended". Here are copies from chrome://media-internals during playback and pause. 


Playing: http://pastebin.com/P5z9vUKz
Paused: http://pastebin.com/MSRckUxv
Log: http://pastebin.com/UuuZKvC3

As you see in the log, the stream was paused for about 8 minutes and I was able to resume it without any issues. 

Well, the best kind of fix is the kind where I don't have to do anything.

I'm not sure about the previous report, but this does not appear to be fixed for me. I can still reproduce in Windows and OSX on 54.0.2840.50.

Still unfixed for me, 54.0.2840.50 linux. 

Still unfixed for me as well, Chrome Version 54.0.2840.59 (64-bit)

#24, #25, #26: Can you report what URLs you are experiencing this issue at, and perhaps a little bit about your network setup? Thanks!

This is using Plex. When you pause for a while in Plex, it will break.

Almost any video will produce this.  

Can confirm. The majority of videos played from Plex after an extended pause, exhibit this issue.

Like others I too am seeing this issue when using Plex. In my chrome://media-internals I see events for PLAY/PAUSE actions (I repeatedly flipped on and off). Playback behaves as expected. In leaving the player in the PAUSE state exactly 15 seconds later I see the pipeline_state change to kSuspending, followed near-instantly thereafter by kSuspended.

When I resume the video (generating a PLAY event) I see the pipeline_state change to kResuming, followed by some (audio|video)_(dds|decoder) messages, ending with a pipeline_state of kPlaying.

This is with Chrome 54.0.2840.71 (64-bit) on Fedora 24 w/ kernel 4.7.6-200.fc24.x86_64. Network topology is totally flat with client and server on the same net. I also see this behavior playing media from a remote server out on the Internet. Firefox is not affected.

Chrome 54.0.2840.59 (64-bit), Linux, still not working.

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

commit aaff1a65fbb4002879616c1657282c07c77c9e75
Author: sandersd <sandersd@chromium.org>
Date: Thu Nov 17 01:47:25 2016

Media: Don't suspend streaming media on Desktop.

Streaming media is always resumed at time 0, but live transcoding
servers (eg. Plex) do not expect this.

BUG= 622313 

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

[modify] https://crrev.com/aaff1a65fbb4002879616c1657282c07c77c9e75/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/aaff1a65fbb4002879616c1657282c07c77c9e75/media/blink/webmediaplayer_impl.h
[modify] https://crrev.com/aaff1a65fbb4002879616c1657282c07c77c9e75/media/blink/webmediaplayer_impl_unittest.cc

That a good news. Waiting when this change will be in the release.

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

commit b8eb5f1dd1b72b54e3fb66d630f5cc4789b941b1
Author: sandersd <sandersd@chromium.org>
Date: Sat Nov 19 04:04:02 2016

Media: Add IsStreaming UMA.

BUG= 622313 

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

[modify] https://crrev.com/b8eb5f1dd1b72b54e3fb66d630f5cc4789b941b1/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/b8eb5f1dd1b72b54e3fb66d630f5cc4789b941b1/tools/metrics/histograms/histograms.xml

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

commit 35d2c3fe00d136c5cdc59f9703c47fba912e5c7b
Author: sandersd <sandersd@chromium.org>
Date: Sat Jan 14 02:04:42 2017

Refactor WebMediaPlayerDelegate interface.

This is part one of two, it changes the interfaces but tries to
maintain most of the old behavior (and client implementations) as
possible. Part two will rewrite WMPI's logic in a simpler way.

This CL includes two fixes to WMPI's logic:
  - We now become non-idle during seek, and so will not suspend
    immediately after completing a seek.
  - We now track non-suspended time after loading progress and will
    resume upon foregrounding (pre-HaveFutureData).

BUG= 622313 

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

[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/content/renderer/media/android/webmediaplayer_android.cc
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/content/renderer/media/android/webmediaplayer_android.h
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/content/renderer/media/renderer_webmediaplayer_delegate.cc
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/content/renderer/media/renderer_webmediaplayer_delegate.h
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/content/renderer/media/renderer_webmediaplayer_delegate_browsertest.cc
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/content/renderer/media/webmediaplayer_ms.cc
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/content/renderer/media/webmediaplayer_ms.h
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/content/renderer/media/webmediaplayer_ms_unittest.cc
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/media/blink/webmediaplayer_delegate.h
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/media/blink/webmediaplayer_impl.h
[modify] https://crrev.com/35d2c3fe00d136c5cdc59f9703c47fba912e5c7b/media/blink/webmediaplayer_impl_unittest.cc

Chrome 58.0.3029.110 (64-bit), Windows 7 Ultimate SP1 (64 bit), still not working.

#39: M58 included the most important changes here. Can you test again with Dev channel, and if you see a problem still, file a new bug with reproduction steps? Thanks!

Resume playback issue is when using Google Chromecast and plex. Version 59.0.3071.115 (Official Build) (64-bit) can resume playback. I'll raise the bug against chromecast.

I don't think this issue has been fixed fully, when serving media via nginx. Playback can't be resumed as described previously.

You can find more information and my efforts to work around the issue by altering Nginx's settings here, nothing worked.
https://github.com/toomuchio/plex-nginx-reverseproxy/issues/21

I'll also note that the issue is not present in Opera which is based on the Chromium engine.

Just tried the dev channel issue is still present there as well, as detailed on git.

It appears to be an issue with Nginx and Chrome, as the pause issue was resolved when connecting directly to Plex or other media servers directly. But when a reverse proxy is put in front, Chrome can't resume after an extended pause same as before. Opera is able to resume fine though I guess the code differs somewhere, perhaps they stayed with the the 50.0 media playback code base.