Intermittent test_BufferingWait_mp4.html | Test timed out.

RESOLVED FIXED in Firefox 46

Status

()

P2
normal
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: KWierso, Assigned: jwwang)

Tracking

({intermittent-failure})

45 Branch
mozilla46
intermittent-failure
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 wontfix, firefox46 fixed, firefox-esr45 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Updated

3 years ago
Depends on: 1238347
(Assignee)

Comment 1

3 years ago
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
(Assignee)

Comment 2

3 years ago
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
(Assignee)

Comment 4

3 years ago
This should also address the problem in bug 1229987 comment 23.
(Assignee)

Comment 5

3 years ago
Created 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.

Review commit: https://reviewboard.mozilla.org/r/30297/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/30297/
Attachment #8706264 - Flags: review?(jyavenard)
Priority: -- → P2
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+
(Assignee)

Comment 7

3 years ago
Thanks for the review!

Comment 9

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/7ea8e549a96f
Status: NEW → RESOLVED
Last Resolved: 3 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)
(Assignee)

Comment 11

3 years ago
No, this bug only affects the test cases.
Flags: needinfo?(jwwang)
Blocks: 1239215
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)
(Assignee)

Comment 13

3 years ago
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?
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
(Assignee)

Comment 15

3 years ago
(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...
(Assignee)

Comment 16

3 years ago
(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)
48 automation job failures were associated with this bug yesterday.

Repository breakdown:
* mozilla-inbound: 32
* fx-team: 10
* mozilla-central: 5
* try: 1

Platform breakdown:
* windows7-32: 30
* windows8-64: 17
* osx-10-6: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1237806&startday=2016-03-22&endday=2016-03-22&tree=all
(Assignee)

Comment 19

3 years ago
Some other timeouts are caused by bug 1258922. debugging...
Depends on: 1258922
Flags: needinfo?(jwwang)
53 automation job failures were associated with this bug yesterday.

Repository breakdown:
* mozilla-inbound: 36
* fx-team: 14
* mozilla-central: 3

Platform breakdown:
* windows7-32: 34
* windows8-64: 19

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1237806&startday=2016-03-23&endday=2016-03-23&tree=all
167 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 114
* fx-team: 38
* mozilla-central: 13
* try: 2

Platform breakdown:
* windows7-32: 97
* windows8-64: 69
* osx-10-6: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1237806&startday=2016-03-21&endday=2016-03-27&tree=all
17 automation job failures were associated with this bug yesterday.

Repository breakdown:
* mozilla-inbound: 8
* fx-team: 8
* mozilla-central: 1

Platform breakdown:
* windows8-64: 11
* windows7-32: 6

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1237806&startday=2016-03-29&endday=2016-03-29&tree=all
21 automation job failures were associated with this bug yesterday.

Repository breakdown:
* fx-team: 10
* mozilla-inbound: 9
* mozilla-central: 2

Platform breakdown:
* windows8-64: 12
* windows7-32: 9

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1237806&startday=2016-04-01&endday=2016-04-01&tree=all
Component: Audio/Video → Audio/Video: Playback
48 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 23
* fx-team: 22
* mozilla-central: 3

Platform breakdown:
* windows8-64: 31
* windows7-32: 17

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1237806&startday=2016-03-28&endday=2016-04-03&tree=all
14 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 13
* fx-team: 1

Platform breakdown:
* windows8-64: 8
* windows7-32: 6

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1237806&startday=2016-04-04&endday=2016-04-10&tree=all
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+
(Reporter)

Comment 27

3 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-esr45/rev/ef722522ea0c
status-firefox-esr45: affected → fixed
5 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 5

Platform breakdown:
* windows7-32: 4
* windows8-64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1237806&startday=2016-04-25&endday=2016-05-01&tree=all
5 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 5

Platform breakdown:
* windows7-32-vm: 3
* linux64: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1237806&startday=2016-06-27&endday=2016-07-03&tree=all
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)
(Assignee)

Comment 32

2 years ago
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.