New issue
Advanced search Search tips

Issue 633620 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Chrome is discarding audio buffer chunks after some seconds

Reported by helio.co...@listenx.com.br, Aug 2 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

Example URL:

Steps to reproduce the problem:
1. start buffering an audio without play
2. play audio after about 30 seconds
3. the song will starts playing from the beginning again

OR

1. play an audio and pause seconds later
2. wait about 30 seconds and play the audio again
3. the song will starts playing from the beginning again

What is the expected behavior?
The browser should play the audio without try to buffering again because the hole audio is already buferred.

What went wrong?
This new version 52 seems to discarding chunks of audio that is already played or buferred. Besides that, if you try to buffer an audio without play for some seconds the browser will discard and will try to buffer again when you play.

Did this work before? Yes Version < 52

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes 

Chrome version: 52.0.2743.82  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 18.0 r0
 
This can happen with servers that don't serve content with range requests. As of M52 we will release idle resources behind the scenes to avoid unnecessary resource consumption.

Do you have a link to a site that has this issue?
Hello!
I´m having the same issue here, chrome ignores the header "Accept-Ranges:none"
and some times is doing many requests with "Range" header and refusing the response with all bytes, with "MediaError Code:2".

How can I make a single request once for all?
My files are generated in real time with expiration token, my application can´t afford this ammount of requests for a single file, even though the entire file was already buffered.
Status: WontFix (was: Unconfirmed)
as per #2, this is by design. Since bug opener didn't provide repro url, no further investigation is actionable.

Sign in to add a comment