MP3 playback stops before reaching the end on server not supporting range-request

VERIFIED FIXED in Firefox 55

Status

()

defect
P1
normal
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: contact, Assigned: cpearce)

Tracking

({nightly-community, regression})

55 Branch
mozilla56
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox54 unaffected, firefox55+ verified, firefox56+ verified)

Details

Attachments

(2 attachments)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170615030208

Steps to reproduce:

- go to http://play.dogmazic.net/index.php#song.php?action=show_song&song_id=25592
- click on the play button


Actual results:

The song ends before the end.


Expected results:

The song should end at the end.
I'm on Firefox Nightly 56 but I have the same issue on Firefox DE 55.0b1 (64 bits).
It works on Firefox 53.0.3.
And working either on 54.0.
Confirming with Nightly on Linux.
Status: UNCONFIRMED → NEW
Has Regression Range: --- → no
Has STR: --- → yes
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
[Tracking Requested - why for this release]:
Jean-Yves, any idea ? A regression from 55 up.
Flags: needinfo?(jyavenard)
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Version: 56 Branch → 55 Branch
[Tracking Requested - why for this release]: regression on media playback

Reverting bug 1347174 and it now works.

STR (a tad quicker than listening to the entire song):
1- Load http://play.dogmazic.net/index.php#song.php?action=show_song&song_id=25592
2- Press the play button
3- Click in the middle of the progress bar at the bottom, so that you seek at around 0:58
4- Audio will stop after a couple of seconds

Jan, I don't think bug 1347174 is actually the culprit, I believe it only exposes an existing issue in the MP3Demuxer.

Maybe related to how when NotifyDataArrived is called, how it refreshes some tables.
Blocks: 1347174
Flags: needinfo?(jyavenard)
Flags: needinfo?(jwwang)
Flags: needinfo?(jh+bugzilla)
setting pref media.cache_readahead_limit to 999999 fixes the problem (more accurately, gets around it)
I don't think the MP3Demuxer is to blame here - as far as I can tell, it's simply reading data and eventually failing to get it:

> [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer GetSamples(1) Begin mOffset=3324992 mNumParsedFrames=3182 mFrameIndex=3181 mTotalFrameLen=3324863 mSamplesPerFrame=1152 mSamplesPerSecond=44100 mChannels=2
> [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer FindNext() Begin mOffset=3324992 mNumParsedFrames=3182 mFrameIndex=3181 mTotalFrameLen=3324863 mSamplesPerFrame=1152 mSamplesPerSecond=44100 mChannels=2
> [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer MP3TrackDemuxer::Read(0828F444 3324992 64)
> [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer MP3TrackDemuxer::Read        -> ReadAt(64)
> [MediaPDecoder #2]: D/MediaResourceIndex 17FFE7C8 ReadAt(0@3324992) copied everything (64) from cache(8192@3317760) :-D -> OK, 64
> [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer FindNext() End mOffset=3325056 mNumParsedFrames=3182 mFrameIndex=3181 frameHeaderOffset=3324992 mTotalFrameLen=3324863 mSamplesPerFrame=1152 mSamplesPerSecond=44100 mChannels=2
> [MediaPDecoder #2]: D/MediaDemuxer MP3Demuxer GetNext() Begin({mStart=3324992 Length()=1045})
> [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer MP3TrackDemuxer::Read(0AF80800 3324992 1045)
> [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer MP3TrackDemuxer::Read        -> ReadAt(1045)
> [MediaPDecoder #2]: D/MediaResourceIndex 17FFE7C8 ReadAt(1045@3324992) copied 960 from cache(8192@3317760) :-), remaining: 85@3325952...
> [MediaPDecoder #2]: D/MediaResourceIndex 17FFE7C8 ReadAt(85@3325952) - length is 0 (too short!), will fallback to blocking read as the caller requested...
> [MediaPDecoder #2]: D/MediaCache Stream 1D377DB8 Seek to 3325952
> [MediaPDecoder #2]: D/MediaCache Stream 1D377DB8 Read at 3325952 count=0
> [MediaPDecoder #2]: D/MediaResourceIndex 17FFE7C8 ReadAt(85@3325952) - fallback uncached read got 0 bytes -> NS_OK, 960
> [MediaPDecoder #2]: D/MediaDemuxer MP3Demuxer GetNext() Exit read=960 frame->Size()=1045
> [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer GetSamples() End mSamples.Size()=0 aNumSamples=0 mOffset=3325056 mNumParsedFrames=3182 mFrameIndex=3181 mTotalFrameLen=3324863 mSamplesPerFrame=1152 mSamplesPerSecond=44100 mChannels=2
> [Main Thread]: D/MediaCache Stream 1D377DB8 at end of stream
> [MediaPDecoder #1]: D/MediaDemuxer MP3Demuxer Reset()

Tracing through the MediaCache, the failing read seems to come from here (https://dxr.mozilla.org/mozilla-central/rev/316014448e427486cce211217e2aee2f18ee3d69/dom/media/MediaCache.cpp#2328) because for some reason mStreamLength is reported as 0.

Poking around further, it seems like at some point, NotifyDataStarted is called with an offset of 0 (and the console shows this assertion: https://dxr.mozilla.org/mozilla-central/rev/316014448e427486cce211217e2aee2f18ee3d69/dom/media/MediaCache.cpp#1813), which will set mChannelOffset to 0.

Then we get a NotifyDataLength with a length of 0, which will set mStreamLength to 0 directly, followed by NotifyDataEnded, which sets mStreamLength to mChannelOffset (https://dxr.mozilla.org/mozilla-central/rev/316014448e427486cce211217e2aee2f18ee3d69/dom/media/MediaCache.cpp#1979), i.e. 0 as well.

The next read from the MediaCache will then presumably run into the situation visible at the end of the attached log.
Flags: needinfo?(jh+bugzilla)
The HTTP server falsely declares it accepts range requests and fails the assertion at http://searchfox.org/mozilla-central/rev/7cc377ce3f0a569c5c9b362d589705cd4fecc0ac/dom/media/MediaCache.cpp#1813.

Reverting bug 1347174 happens to work because it downloads the entire file into the cache before seek starts and therefore no HTTP request is needed for seeking (and will not fail the assertion).
No longer blocks: 1347174
Flags: needinfo?(jwwang)
It is interesting that the HTTP response code is 206 in Chrome when opening the link (http://play.dogmazic.net/index.php#song.php?action=show_song&song_id=25592). However it is 200 in Firefox which means range requests not supported. I wonder what makes the difference.
Flags: needinfo?(schien)
For small bitrate content (such as audio-only file), which are typically read from the beginning to the end, it may be worth downloading the whole lot rather than blocking very early on waiting for another seek (Which are very slow to start with).

A limit per seconds on how much we can download ahead isn't really that useful for audio file. For big video file sure..

Using a combination of size and duration may be preferable anyway.
At the very least, if range request isn't supported, it shouldn't attempt to seek.
(In reply to Jan Henning [:JanH] from comment #8)
> Created attachment 8878929 [details]
> MP3 early stop 2.log.7z
> 
> I don't think the MP3Demuxer is to blame here - as far as I can tell, it's
> simply reading data and eventually failing to get it:
> 
> > [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer GetSamples(1) Begin mOffset=3324992 mNumParsedFrames=3182 mFrameIndex=3181 mTotalFrameLen=3324863 mSamplesPerFrame=1152 mSamplesPerSecond=44100 mChannels=2
> > [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer FindNext() Begin mOffset=3324992 mNumParsedFrames=3182 mFrameIndex=3181 mTotalFrameLen=3324863 mSamplesPerFrame=1152 mSamplesPerSecond=44100 mChannels=2
> > [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer MP3TrackDemuxer::Read(0828F444 3324992 64)
> > [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer MP3TrackDemuxer::Read        -> ReadAt(64)
> > [MediaPDecoder #2]: D/MediaResourceIndex 17FFE7C8 ReadAt(0@3324992) copied everything (64) from cache(8192@3317760) :-D -> OK, 64
> > [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer FindNext() End mOffset=3325056 mNumParsedFrames=3182 mFrameIndex=3181 frameHeaderOffset=3324992 mTotalFrameLen=3324863 mSamplesPerFrame=1152 mSamplesPerSecond=44100 mChannels=2
> > [MediaPDecoder #2]: D/MediaDemuxer MP3Demuxer GetNext() Begin({mStart=3324992 Length()=1045})
> > [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer MP3TrackDemuxer::Read(0AF80800 3324992 1045)
> > [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer MP3TrackDemuxer::Read        -> ReadAt(1045)
> > [MediaPDecoder #2]: D/MediaResourceIndex 17FFE7C8 ReadAt(1045@3324992) copied 960 from cache(8192@3317760) :-), remaining: 85@3325952...
> > [MediaPDecoder #2]: D/MediaResourceIndex 17FFE7C8 ReadAt(85@3325952) - length is 0 (too short!), will fallback to blocking read as the caller requested...
> > [MediaPDecoder #2]: D/MediaCache Stream 1D377DB8 Seek to 3325952
> > [MediaPDecoder #2]: D/MediaCache Stream 1D377DB8 Read at 3325952 count=0
> > [MediaPDecoder #2]: D/MediaResourceIndex 17FFE7C8 ReadAt(85@3325952) - fallback uncached read got 0 bytes -> NS_OK, 960
> > [MediaPDecoder #2]: D/MediaDemuxer MP3Demuxer GetNext() Exit read=960 frame->Size()=1045
> > [MediaPDecoder #2]: V/MediaDemuxer MP3Demuxer GetSamples() End mSamples.Size()=0 aNumSamples=0 mOffset=3325056 mNumParsedFrames=3182 mFrameIndex=3181 mTotalFrameLen=3324863 mSamplesPerFrame=1152 mSamplesPerSecond=44100 mChannels=2
> > [Main Thread]: D/MediaCache Stream 1D377DB8 at end of stream
> > [MediaPDecoder #1]: D/MediaDemuxer MP3Demuxer Reset()
> 
> Tracing through the MediaCache, the failing read seems to come from here
> (https://dxr.mozilla.org/mozilla-central/rev/
> 316014448e427486cce211217e2aee2f18ee3d69/dom/media/MediaCache.cpp#2328)
> because for some reason mStreamLength is reported as 0.
> 
> Poking around further, it seems like at some point, NotifyDataStarted is
> called with an offset of 0 (and the console shows this assertion:
> https://dxr.mozilla.org/mozilla-central/rev/
> 316014448e427486cce211217e2aee2f18ee3d69/dom/media/MediaCache.cpp#1813),
> which will set mChannelOffset to 0.
> 
> Then we get a NotifyDataLength with a length of 0, which will set
> mStreamLength to 0 directly, followed by NotifyDataEnded, which sets
> mStreamLength to mChannelOffset
> (https://dxr.mozilla.org/mozilla-central/rev/
> 316014448e427486cce211217e2aee2f18ee3d69/dom/media/MediaCache.cpp#1979),
> i.e. 0 as well.
> 
> The next read from the MediaCache will then presumably run into the
> situation visible at the end of the attached log.

That would explain why seeking fail.

However, if you let the song play to the end, without seeking either, playback stops early and doesn't play to the end.
(In reply to Jean-Yves Avenard [:jya] from comment #13)
> That would explain why seeking fail.
> 
> However, if you let the song play to the end, without seeking either,
> playback stops early and doesn't play to the end.

I didn't seek - that log is from simply hitting play and then waiting a minute or so until playback stops prematurely.
See Also: → 1374199
Priority: -- → P1
Summary: Ampache song stops playing → MP3 playback stops before reaching the end on server not supporting range-request
The 200 status code issue only happens when testing with Firefox Linux UA string. Firefox Mac received 206 status code as Chrome did. It's definitely a webcompat issue but not sure if it has direct relation with this bug.
(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #15)
> The 200 status code issue only happens when testing with Firefox Linux UA
> string. Firefox Mac received 206 status code as Chrome did. It's definitely
> a webcompat issue but not sure if it has direct relation with this bug.

Playback will be good when range request is supported. Otherwise, playback will error out when seeking or resuming download (both require range request).
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #16)
> (In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment
> #15)
> > The 200 status code issue only happens when testing with Firefox Linux UA
> > string. Firefox Mac received 206 status code as Chrome did. It's definitely
> > a webcompat issue but not sure if it has direct relation with this bug.
> 
> Playback will be good when range request is supported. Otherwise, playback
> will error out when seeking or resuming download (both require range
> request).

then read ahead limit should be disabled in this case.

That still begs the question on why resume needs seeking.
Flags: needinfo?(schien)
tracking as audio playback regression in 55.
(In reply to Jean-Yves Avenard [:jya] from comment #12)
> At the very least, if range request isn't supported, it shouldn't attempt to
> seek.

IIRC, the MediaCache has logic in it to keep downloading from the current position until the seek target is buffered if a MediaResource seeks and HTTP1.1 Byte Range Requests are not supported by the server
(In reply to Chris Pearce (:cpearce) from comment #19)
> (In reply to Jean-Yves Avenard [:jya] from comment #12)
> > At the very least, if range request isn't supported, it shouldn't attempt to
> > seek.
> 
> IIRC, the MediaCache has logic in it to keep downloading from the current
> position until the seek target is buffered if a MediaResource seeks and
> HTTP1.1 Byte Range Requests are not supported by the server

Though, I should qualify this the reason we're seeking here is that the server falsely advertises that it supports byte range requests, but actually does not.
(In reply to Jean-Yves Avenard [:jya] from comment #11)
> For small bitrate content (such as audio-only file), which are typically
> read from the beginning to the end, it may be worth downloading the whole
> lot rather than blocking very early on waiting for another seek (Which are
> very slow to start with).
> 
> A limit per seconds on how much we can download ahead isn't really that
> useful for audio file. For big video file sure..
> 
> Using a combination of size and duration may be preferable anyway.

I think not throttling the download when the resource is small, say under 8 MB as our telemetry shows 92% of media files are [1], is a great idea.

[1] https://mzl.la/2rxt0Sk
Depends on: 1374475
(In reply to Chris Pearce (:cpearce) from comment #20)
> Though, I should qualify this the reason we're seeking here is that the
> server falsely advertises that it supports byte range requests, but actually
> does not.

See comment 10, the server does actually support range requests when using Chrome. There might be something wrong in Necko so the server falsely returns 200 instead of 206 to support range requests.
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #22)
> There might be something wrong in Necko so the server falsely
> returns 200 instead of 206 to support range requests.

I have to say this statement is wrong based on comment #15. This is server-side's decision since changing UA string will lead to different HTTP response. We could ask webcompat team to contact the website owner to remove the special handling on Firefox Linux, however it will be a totally different issue.
(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #23)
> (In reply to JW Wang [:jwwang] [:jw_wang] from comment #22)
> > There might be something wrong in Necko so the server falsely
> > returns 200 instead of 206 to support range requests.
> 
> I have to say this statement is wrong based on comment #15. This is
> server-side's decision since changing UA string will lead to different HTTP
> response. We could ask webcompat team to contact the website owner to remove
> the special handling on Firefox Linux, however it will be a totally
> different issue.

Good. Then we should notify the site to fix the server side issue. Even if we handle response=200 correctly in our code, unable to seek to an arbitrary position during playback makes Firefox looks inferior to Chrome.
I've landed a work around in Bug 1374475 to stop us from throttling the download for media <= 8MB in size.
See Also: → 1364476
Depends on: 1374969
Mike,
Per comment 23 and 24, can you help talk to the website?
Flags: needinfo?(miket)
(In reply to Blake Wu [:bwu][:blakewu] from comment #26)
> Mike,
> Per comment 23 and 24, can you help talk to the website?

Sure thing. Adam, can you try to get in touch? See Comment #15 as well.

Unsure if we should move this bug to Tech Evangelism::Desktop, or if there's code that will land here. If someone has an idea, feel free to move!
Flags: needinfo?(miket) → needinfo?(astevenson)
Dogmazic has a freenode channel #dogmazic. A person commented that "ampache propels play.dogmazic.net" and to report the issue here: https://github.com/ampache/ampache.

Is it possible to confirm if the issue is with ampache, or the Dogmazic server configuration?
Flags: needinfo?(astevenson)
I confirm that it is not just a Dogmazic issue. I have the same issue on my self-hosted version. Ampache has a chan on freenode too: #ampache.
Is this a Tech Evangelism bug at this point?
Flags: needinfo?(bwu)
Yeah. I think so.
Flags: needinfo?(bwu)
Did the dogmazic site change? I can no longer repro this bug in a build without the work arounds we've deployed.
Component: Audio/Video: Playback → Desktop
Product: Core → Tech Evangelism
Version: 55 Branch → Firefox 55
(In reply to Chris Pearce (:cpearce) from comment #32)
> Did the dogmazic site change? I can no longer repro this bug in a build
> without the work arounds we've deployed.

I think so. Kaku can't repro the same issue anymore since yesterday.
Hello,
It's working on Dogmazik but I'm still encountering this issue on my instance (that didn't changed). What can I do on Ampache to fix that problem and make a pull request?
Simounet: Can you provide a link to your instance which is exhibiting this problem? I'm trying to understand the underlying issue, but I can no longer reproduce it.
Flags: needinfo?(contact)
I have looked into this. I can still repro the issue in Firefox 54 and in Firefox 56 if I include JW's second patch from bug 1375772 which reverts the throttling changes we've made recently.

I believe I've figured out the problem.

The length of the stream is 4565414 bytes. Our media stack makes a byte range request for "Range: bytes=4565414-", and the server returns a 200 response with "Content-Length: 0", which causes us to changes the length of the stream as described in comment 8.

So I think the problem with the server is that it's returning a 200 response for a "Range: bytes=$(contentLength)-" request. Our code expects a 206 response of zero length, or a 416 "Requested Range Not Satisfiable" response as, my web server running Apache/1.3.41 responds with.

We end up making a "Range: $(contentLength)-" request like so: when our download reaches end of stream, our ChannelMediaResource::OnStopRequest() [1] is called. This branch in ChannelMediaResource::OnStopRequest() gets run:

  // Note that aStatus might have succeeded --- this might be a normal close
  // --- even in situations where the server cut us off because we were
  // suspended. So we need to "reopen on error" in that case too. The only
  // cases where we don't need to reopen are when *we* closed the stream.
  // But don't reopen if we need to seek and we don't think we can... that would
  // cause us to just re-read the stream, which would be really bad.
  if (mReopenOnError &&
      aStatus != NS_ERROR_PARSED_DATA_CACHED && aStatus != NS_BINDING_ABORTED &&
      (mOffset == 0 || mCacheStream.IsTransportSeekable())) {
    // If the stream did close normally, then if the server is seekable we'll
    // just seek to the end of the resource and get an HTTP 416 error because
    // there's nothing there, so this isn't bad.
    nsresult rv = CacheClientSeek(mOffset, false);
    if (NS_SUCCEEDED(rv))
      return rv;
    // If the reopen/reseek fails, just fall through and treat this
    // error as fatal.
  }

mReopenOnError==true, mOffset==4565414 (the stream length), the transport is seekable.

Note the comment mentioning the expected 416 response.

So we take the branch that calls CacheClientSeek(), which causes us to open a new channel and request "Range: 4565414-", which results in the server returning a 200 response with 0 length, which causes us to enter the path mentioned in comment 8 above.

This regressed when we changed our throttling logic to throttle more aggressively, as if we suspend the stream, when we resume [2] we end up calling through to ChannelMediaResource::Resume() which sets mReopenOnError to true [3], which causes us to take this branch.

We suspend by just stopping reading from the channel IIRC, so we set mReopenOnError to true to ensure that if the channel times out we can restart it. So I think we should *not* be messing with the logic surrounding mReopenOnError.

However, I do think it's reasonable to not request a byte range of $contentLength-, as the server has told us there is no such content. So I think we should change OnStopRequest() to not seek (i.e. reopen) the channel if (mOffset == contentLength). Making that change makes the Dogmazik server (in its current, possibly not the same as when the bug was originally filed, configuration) now work.

That also means we don't need to worry about a 416 response from an Apache server in this case too.


[1] https://searchfox.org/mozilla-central/rev/a3a739de04ee6134c11546568a33dbb6a6a29907/dom/media/MediaResource.cpp#398
[2] https://searchfox.org/mozilla-central/rev/a3a739de04ee6134c11546568a33dbb6a6a29907/dom/media/MediaCache.cpp#1407
[3] https://searchfox.org/mozilla-central/rev/a3a739de04ee6134c11546568a33dbb6a6a29907/dom/media/MediaResource.cpp#793
Comment on attachment 8883138 [details]
Bug 1373618 - Prevent ChannelMediaResource from making a "Range: bytes=$length-" request at end of stream.

https://reviewboard.mozilla.org/r/154074/#review159220

I am worried that the server might lie about the length too. So it is possible for some other server to return a 206 response and we find out there are more bytes to download after 4565414 (the former length reported by the server).
Attachment #8883138 - Flags: review?(jwwang) → review+
Btw, does this patch fix the issue in comment 6 which I think is a different issue than comment 0?
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #39)
> Btw, does this patch fix the issue in comment 6

This patch fixes the issue in comment 6, we'll hit this bug once the last chunk of the resource is downloaded, as that triggers the OnStopRequest() which changes our length to 0. I think jya observes this faster than we do because he's in France and so is closer to the server and thus the connection to the server is faster.

> which I think is a different issue than comment 0?

As best I can tell, the issue mentioned in comment 6 is the same issue as in comment 0. When reproing either case (in Firefox 54.0.1 Release) I see the same in Firefox's developer tool's Network monitor; I see the failure occur when the media stack makes a byte range request for "Range: bytes=4565414-", and the server returns a 0 length response.
Moving this bug back to core, as I think we've addressed it with code rather than evangelism.
Component: Desktop → Audio/Video: Playback
Product: Tech Evangelism → Core
Version: Firefox 55 → 55 Branch
Pushed by cpearce@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/da639765d999
Prevent ChannelMediaResource from making a "Range: bytes=$length-" request at end of stream. r=jwwang
I need to remember to uplift.
Flags: needinfo?(cpearce)
https://hg.mozilla.org/mozilla-central/rev/da639765d999
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Assignee: nobody → cpearce
Flags: needinfo?(cpearce)
jw: Can you please request beta uplift on this and anything else we need to fix any regressions we have from the throttling changes on beta please?
Flags: needinfo?(jwwang)
Sure. Collecting changesets for uplift.
Comment on attachment 8883138 [details]
Bug 1373618 - Prevent ChannelMediaResource from making a "Range: bytes=$length-" request at end of stream.

Approval Request Comment
[Feature/Bug causing the regression]:unknown
[User impact if declined]:playback stops abnormally before it reaches the end.
[Is this code covered by automated tests?]:no
[Has the fix been verified in Nightly?]:yes
[Needs manual test from QE? If yes, steps to reproduce]: comment 0.
[List of other uplifts needed for the feature/fix]:none
[Is the change risky?]:no
[Why is the change risky/not risky?]:the change is simple and only very few web servers exhibit such a problem.
[String changes made/needed]:none
Flags: needinfo?(jwwang)
Attachment #8883138 - Flags: approval-mozilla-beta?
Comment on attachment 8883138 [details]
Bug 1373618 - Prevent ChannelMediaResource from making a "Range: bytes=$length-" request at end of stream.

prevent unnecessary seek at end of stream that breaks some servers, beta55+
Attachment #8883138 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
I have the same results on Firefox 55 beta 12 as on the Nightly affected build under Win 10 and Mac OS X. The playback ends 5 seconds before the progress bar reaches the end. 
This happens also on Chrome or if I save the file locally as mp3.

Is this expected? Are there other ways I could reproduce the initial issue and verify the fix? Thank you!
Flags: needinfo?(cpearce)
I just checked (Firefox 56.0a1 2017-07-26) with my Ampache instance and the media.cache_readahead_limit preference set to it's default value (60) and everything seems to be fine.
Flags: needinfo?(contact)
Simounet, could you please check the issue is no longer present on Firefox 55 Release Candidate too? Thank you!

https://archive.mozilla.org/pub/firefox/candidates/55.0-candidates/build1/
Flags: needinfo?(contact)
I tested it right now. It is working as expected.
Flags: needinfo?(contact)
I'll assume the ni? on me is now no longer needed. Please re-request if that's not the case.
Flags: needinfo?(cpearce)
Thanks, Simounet! Marking as verified based on your comments.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.