Closed
Bug 1126052
Opened 10 years ago
Closed 10 years ago
Turn test_SeekTwice_mp4.html back on
Categories
(Core :: Audio/Video, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla38
Tracking | Status | |
---|---|---|
firefox38 | --- | fixed |
People
(Reporter: bholley, Assigned: bholley)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
393.44 KB,
text/plain
|
Details |
The tests in bug 1121692 went intermittently orange, and got disabled. These were the first and only in-tree tests for the MSE code that we're planning to ship on youtube. I think figuring out why they're timing out is pretty important.
Assignee | ||
Comment 1•10 years ago
|
||
Try push with some logging: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4f0750abe27e
Assignee | ||
Comment 2•10 years ago
|
||
So, one of the problems here is that we don't have an h264 story on winxp (duh), and don't have a way to mark the test as skip-if in the winxp case. I'll file a bug about that.
However, this did go orange at least once on win7 with my logging machinery. The log is here: https://treeherder.mozilla.org/logviewer.html#?job_id=4475740&repo=try
I've pruned the log of unrelated stuff locally (especially other decoders that get shutdown off a timer gc), and will upload that.
Assignee | ||
Comment 3•10 years ago
|
||
Comment 4•10 years ago
|
||
This *should* work:
skip-if = (os == "win" && os_version == "5.1")
Updated•10 years ago
|
Priority: -- → P2
Assignee | ||
Comment 5•10 years ago
|
||
bug 1126465 fixes one of the failure modes, but as [1] shows, not all (I'd seen this second failure mode before on the original push too).
Pushing with more logging to see if I can suss out the second failure: https://treeherder.mozilla.org/#/jobs?repo=try&revision=502857b1c8e3
[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=5e55dfa4445a
Assignee | ||
Comment 6•10 years ago
|
||
Comment 5 wasn't able to reproduce any failure in the test with logging (and that was a week ago, which is an eternity in the MSE codebase).
I just did another set of pushes with the same results. The first just turns the test back on, the second does so and activates the logging:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=714cc4e2117e
https://treeherder.mozilla.org/#/jobs?repo=try&revision=27107a65b2ee
So far those look pretty green. Ryan, are you comfortable with me turning the test back on, or are there any other steps I should take?
Flags: needinfo?(ryanvm)
Comment 7•10 years ago
|
||
Are we going to leave the logging on when it's re-enabled? If so, go for it. Try doesn't lie (usually) :)
Flags: needinfo?(ryanvm)
Assignee | ||
Comment 8•10 years ago
|
||
Pushed per IRC conversation with RyanVM:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6f4dcfcb3843
Comment 9•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox38:
--- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in
before you can comment on or make changes to this bug.
Description
•