Open Bug 682141 Opened 13 years ago Updated 2 years ago

Intermittent failure: /tests/content/media/test/test_fragment_play.html | big.wav#t=,5 fragment test: paused currentTime is 4.95 < 5.079274 < 5.05 ? 5.079274

Categories

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

x86
All
defect

Tracking

()

People

(Reporter: mdas, Unassigned)

References

Details

(Keywords: intermittent-failure, regression, Whiteboard: [parts of test disabled])

Attachments

(2 files, 1 obsolete file)

http://tbpl.allizom.org/php/getParsedLog.php?id=6127342&full=1 Rev3 MacOSX Snow Leopard 10.6.2 mozilla-inbound debug test mochitests-1/5 on 2011-08-25 13:19:04 PDT for push fdf4c318a165 71684 INFO TEST-PASS | /tests/content/media/test/test_fragment_play.html | big.wav#t=2.5,5.5 fragment test: seeked currentTime is 2.5 != 2.5 71685 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_fragment_play.html | big.wav#t=2.5,5.5 fragment test: paused currentTime is 5.45 < 5.717047 < 5.55 ? 5.717047 71686 INFO TEST-PASS | /tests/content/media/test/test_fragment_play.html | big.wav#t=,5 fragment test: paused currentTime is 4.95 < 5.027334 < 5.05 ? 5.027334
Summary: /tests/content/media/test/test_fragment_play.html | big.wav#t=2.5,5.5 fragment test: paused currentTime is 5.45 < 5.717047 < 5.55 ? 5.717047 → Intermittent failure: /tests/content/media/test/test_fragment_play.html | big.wav#t=2.5,5.5 fragment test: paused currentTime is 5.45 < 5.717047 < 5.55 ? 5.717047
Whiteboard: [orange]
Looks like it's not possible to reliably test what this test is testing. I'll disable or todo for now I think.
Assignee: nobody → chris.double
Attached patch Mark test as 'todo' (deleted) — — Splinter Review
I've marked the failing test as 'todo'. The issue is that we read the 'currentTime' when the video is paused, but this time can vary depending on the data held in the sound buffers. Because it varies it is prone to intermittent failures.
Attachment #555926 - Flags: review?(chris)
Attachment #555926 - Flags: review?(chris) → review+
http://hg.mozilla.org/mozilla-central/rev/a6c42dc89a06 Leaving open, since test is marked as todo and not sure if the work to fix will be done here or not. Please close if desired - thanks :-)
Status: NEW → ASSIGNED
Whiteboard: [orange][inbound] → [orange]
Target Milestone: --- → mozilla9
Version: unspecified → Trunk
Summary: Intermittent failure: /tests/content/media/test/test_fragment_play.html | big.wav#t=2.5,5.5 fragment test: paused currentTime is 5.45 < 5.717047 < 5.55 ? 5.717047 → Intermittent failure: /tests/content/media/test/test_fragment_play.html | big.wav#t=,5 fragment test: paused currentTime is 4.95 < 5.079274 < 5.05 ? 5.079274
OS: Mac OS X → All
Depends on: 720248
Attached patch mark another subtest as todo (obsolete) (deleted) — — Splinter Review
It looks like cdouble missed a subtest that should've been marked 'todo' with the earlier patch; here's another patch. http://tbpl.mozilla.org/?tree=Try&rev=5b6ea51a1c22
Attachment #594558 - Flags: review?(cpearce)
Comment on attachment 594558 [details] [diff] [review] mark another subtest as todo Review of attachment 594558 [details] [diff] [review]: ----------------------------------------------------------------- OK. We should re-enable these TODOs once bug 720248 is fixed.
Attachment #594558 - Flags: review?(cpearce) → review+
Attached patch mark another subtest as todo (r2) (deleted) — — Splinter Review
I updated the todo strings on all three disabled tests to mention bug 720248 and pushed to inbound. http://hg.mozilla.org/integration/mozilla-inbound/rev/3f2cf0c4a67e
Attachment #594558 - Attachment is obsolete: true
Attachment #594629 - Flags: review+
Comment on attachment 594629 [details] [diff] [review] mark another subtest as todo (r2) Proposing this test-only change be uplifted to -aurora to reduce sheriff workload. [Approval Request Comment] Regression caused by (bug #): unknown. User impact if declined: continued orange noise on aurora builds Testing completed (on m-c, etc.): 2 days with no further orange from this test on m-c. Risk to taking this patch (and alternatives if risky): minimal; test-only change. String changes made by this patch: none.
Attachment #594629 - Flags: approval-mozilla-aurora?
Comment on attachment 594629 [details] [diff] [review] mark another subtest as todo (r2) [Triage Comment] Test only fix - approved for Aurora 12.
Attachment #594629 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/f9b5e1f66169 I'm not marking this fixed in anything since the actual bug is still there, this just makes the orange stop.
(In reply to Zack Weinberg (:zwol) from comment #821) > https://hg.mozilla.org/releases/mozilla-aurora/rev/f9b5e1f66169 > > I'm not marking this fixed in anything since the actual bug is still there, > this just makes the orange stop. I'll mark it status-12:fixed due to it showing up on triage query(ies) of mine. Though it does not fix the orange, we likely won't fix the orange on the 12 train, and this *does* stop it from reporting orange.
Target Milestone: mozilla9 → ---
Whiteboard: [orange] → [orange][parts of test disabled]
Whiteboard: [orange][parts of test disabled] → [parts of test disabled]
Assignee: cajbir.bugzilla → nobody
Component: Audio/Video → Audio/Video: Playback
(In reply to OrangeFactor Robot from comment #833) > 43 automation job failures were associated with this bug in the last 7 days. > > Repository breakdown: > * mozilla-inbound: 27 > * mozilla-central: 15 > * fx-team: 1 > > Platform breakdown: > * b2g-emu-ics: 13 > * linux64: 9 > * linux32: 6 > * windows7-32: 5 > * osx-10-10: 3 > * windowsxp: 2 > * windows8-64: 2 > * osx-10-6: 2 > * android-2-3-armv7-api9: 1 > > For more details, see: > https://brasstacks.mozilla.com/orangefactor/ > ?display=Bug&bugid=682141&startday=2015-11-16&endday=2015-11-22&tree=all Fallout from bug 1222866?
Flags: needinfo?(jyavenard)
I wonder if the 3rd commit (the fix for the 9.287982 != 9.287981) got committed into central. But seeing that there's not been any since the 22nd, my guess is that we're just seeing the failures during the original commit and the following backout and central not having done the proper merge
Flags: needinfo?(jyavenard)
Yes; it's backed down to 0 since the 20th where it reappeared. So all good now
P5. 1 failure on trunk in the past week.
Priority: -- → P5
No assignee, updating the status.
Status: ASSIGNED → NEW
No assignee, updating the status.
No assignee, updating the status.
No assignee, updating the status.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: