Closed Bug 1237806 Opened 8 years ago Closed 8 years ago

Intermittent test_BufferingWait_mp4.html | Test timed out.

Categories

(Core :: Audio/Video: Playback, defect, P2)

Product:
Core
Component:
Audio/Video: Playback
Version:
45 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla46
Tracking Flags:
Tracking Status
firefox45 --- wontfix
firefox46 --- fixed
firefox-esr45 --- fixed

People

(Reporter: KWierso, Assigned: jwwang)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

MozReview Request: Bug 1237806 - update playback position before entering buffering mode so the currentTime of the media element is more accurate during buffering. r=jya.
58 bytes, text/x-review-board-request
jya
: review+
Sylvestre
: approval-mozilla-esr45+
Details
Depends on: 1238347
44875 INFO Got a waiting event at 2.356824 which is smaller than 2.36843. (https://hg.mozilla.org/mozilla-central/file/c33f30666b37dbceffb9fbe5089a668db8893a85/dom/media/mediasource/test/test_BufferingWait_mp4.html#l53)

This timeout is not caused by the prerolling bug 1238347 because currentTime is greater than 1.57895 which means playback must have been started.
No longer depends on: 1238347
https://treeherder.mozilla.org/#/jobs?repo=try&revision=20d1fde10638&selectedJob=15265328
It can be easily reproduced by changing the interval of MDSM::UpdatePlaybackPositionPeriodically(). (https://hg.mozilla.org/try/rev/02b78f59ac82)

The fix is simple. We just need to update playback position again before entering BUFFERING mode so the currentTime of the media element would be more accurate.
Assignee: nobody → jwwang
This should also address the problem in bug 1229987 comment 23.
Comment on attachment 8706264 [details]
MozReview Request: Bug 1237806 - update playback position before entering buffering mode so the currentTime of the media element is more accurate during buffering. r=jya.

mozreview crashes whenever i attempt to r+ it..
Attachment #8706264 - Flags: review?(jyavenard) → review+
Thanks for the review!
https://hg.mozilla.org/mozilla-central/rev/7ea8e549a96f
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox46: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
JW: is your playback position fix something we should uplift to Aurora 45? Can this problem affect real world content?
Flags: needinfo?(jwwang)
No, this bug only affects the test cases.
Flags: needinfo?(jwwang)
Please request esr45 approval on this, assuming the risk is sufficiently low (OrangeFactor confirms that 45 is still hitting this failure intermittently).
status-firefox45: --- → wontfix
status-firefox-esr45: --- → affected
Flags: needinfo?(jwwang)
Comment on attachment 8706264 [details]
MozReview Request: Bug 1237806 - update playback position before entering buffering mode so the currentTime of the media element is more accurate during buffering. r=jya.

[Approval Request Comment]
User impact if declined:Intermittent test case failures which bother Sheriff and QA
Fix Landed on Version:46
Risk to taking this patch (and alternatives if risky): Low. The change is very simple.
String or UUID changes made by this patch: none
Flags: needinfo?(jwwang)
Attachment #8706264 - Flags: approval-mozilla-esr45?
(In reply to OrangeFactor Robot from comment #14)
> 34 automation job failures were associated with this bug yesterday.
> 
> Repository breakdown:
> * mozilla-inbound: 28
> * fx-team: 5
> * mozilla-central: 1
> 
> Platform breakdown:
> * windows7-32: 21
> * windows8-64: 13
> 
> For more details, see:
> https://brasstacks.mozilla.com/orangefactor/
> ?display=Bug&bugid=1237806&startday=2016-03-21&endday=2016-03-21&tree=all

checking...
(In reply to OrangeFactor Robot from comment #14)
> 34 automation job failures were associated with this bug yesterday.
> 
> Repository breakdown:
> * mozilla-inbound: 28
> * fx-team: 5
> * mozilla-central: 1
> 
> Platform breakdown:
> * windows7-32: 21
> * windows8-64: 13
> 
> For more details, see:
> https://brasstacks.mozilla.com/orangefactor/
> ?display=Bug&bugid=1237806&startday=2016-03-21&endday=2016-03-21&tree=all

Some of recent timeouts are caused by bug 1258627.
Depends on: 1258627
(In reply to JW Wang [:jwwang] from comment #16)
> (In reply to OrangeFactor Robot from comment #14)
> > 34 automation job failures were associated with this bug yesterday.
> > 
> > Repository breakdown:
> > * mozilla-inbound: 28
> > * fx-team: 5
> > * mozilla-central: 1
> > 
> > Platform breakdown:
> > * windows7-32: 21
> > * windows8-64: 13
> > 
> > For more details, see:
> > https://brasstacks.mozilla.com/orangefactor/
> > ?display=Bug&bugid=1237806&startday=2016-03-21&endday=2016-03-21&tree=all
> 
> Some of recent timeouts are caused by bug 1258627.

this is getting very frequent
Flags: needinfo?(jwwang)
Some other timeouts are caused by bug 1258922. debugging...
Depends on: 1258922
Flags: needinfo?(jwwang)
Component: Audio/Video → Audio/Video: Playback
Comment on attachment 8706264 [details]
MozReview Request: Bug 1237806 - update playback position before entering buffering mode so the currentTime of the media element is more accurate during buffering. r=jya.

Simplify the life of sheriff, taking it.
Should be in 45.1.0
Attachment #8706264 - Flags: approval-mozilla-esr45? → approval-mozilla-esr45+
What has happened in the past week for those to come back?
Flags: needinfo?(gsquelart)
It looks like playback didn't resume after data was added after the first 'waiting' event.

In the past week there are only 4 occurrences within 4 hours of each other on 28 June.
The best candidate is bug 1281115 (add SetSeekThreshold for ffmpeg), which landed just before that and was backed-out shortly after for causing other timeouts.

So we're probably in the clear now. I'll add a note in bug 1281115 to watch out for this timeout too.
Flags: needinfo?(gsquelart)
https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-inbound&job_id=30771818#L2935

Decoder=111824a0 GetMediaTime=1623945 GetClock=1623945 mState=DECODING mPlayState=3 mDecodingFirstFrame=0 IsPlaying=0 mAudioStatus=waiting mVideoStatus=pending mDecodedAudioEndTime=2414873 mDecodedVideoEndTime=1696666 mIsAudioPrerolling=0 mIsVideoPrerolling=1:

Playback is not started because video is prerolling which is because of the pending video request (mVideoStatus=pending). We should check why the video request is not resolved.
I don't see how it could be related to bug 12811115. That bug is ffmpeg related. 3 of the failures were on Windows where ffmpeg isn't used (and the test is about MP4)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: