Closed Bug 1154016 Opened 10 years ago Closed 6 years ago

Intermittent TEST-UNEXPECTED-TIMEOUT | /media-source/mediasource-duration.html | expected OK

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox40 --- affected

People

(Reporter: RyanVM, Assigned: jya)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

Disable test for intermittent failures
1.21 KB, patch
karlt
: review+
Details | Diff | Splinter Review
05:12:43 INFO - TEST-START | /media-source/mediasource-duration.html 05:12:43 INFO - PROCESS | 3060 | WARNING: content window passed to PrivateBrowsingUtils.isWindowPrivate. Use isContentWindowPrivate instead (but only for frame scripts). 05:12:43 INFO - PROCESS | 3060 | pbu_isWindowPrivate@resource://gre/modules/PrivateBrowsingUtils.jsm:25:14 05:12:43 INFO - PROCESS | 3060 | nsBrowserAccess.prototype.openURI@chrome://browser/content/browser.js:15425:21 05:12:43 INFO - PROCESS | 3060 | __marionetteFunc@dummy file:19:30 05:12:43 INFO - PROCESS | 3060 | @dummy file:28:3 05:12:43 INFO - PROCESS | 3060 | executeWithCallback@chrome://marionette/content/listener.js:724:5 05:12:43 INFO - PROCESS | 3060 | executeAsyncScript@chrome://marionette/content/listener.js:617:3 05:12:43 INFO - PROCESS | 3060 | E/MPEG4Extractor( 3060): No width or height, assuming worst case 1080p 05:12:43 INFO - PROCESS | 3060 | E/MPEG4Extractor( 3060): No width or height, assuming worst case 1080p 05:12:43 INFO - PROCESS | 3060 | E/MPEG4Extractor( 3060): No width or height, assuming worst case 1080p 05:12:43 INFO - PROCESS | 3060 | E/MPEG4Extractor( 3060): No width or height, assuming worst case 1080p 05:13:03 INFO - TEST-UNEXPECTED-TIMEOUT | /media-source/mediasource-duration.html | expected OK 05:13:03 INFO - TEST-INFO took 20002ms
Attached patch Disable test for intermittent failures (obsolete) — — Splinter Review
Disable test, will revisit once new mediasource architecture is active.
Attachment #8607286 - Flags: review?(karlt)
Assignee: nobody → jyavenard
Status: NEW → ASSIGNED
Comment on attachment 8607286 [details] [diff] [review] Disable test for intermittent failures Please disable only on winnt platforms with mp4, as that is where the intermittent failures have been reported.
Attachment #8607286 - Flags: review?(karlt) → review-
Blocks: 1066467
Keywords: leave-open
(In reply to Karl Tomlinson (ni?:karlt) from comment #52) > Comment on attachment 8607286 [details] [diff] [review] > Disable test for intermittent failures > > Please disable only on winnt platforms with mp4, as that is where the > intermittent failures have been reported. you mean windows ?
only disabling it on windows
Attachment #8607338 - Flags: review?(karlt)
Attachment #8607286 - Attachment is obsolete: true
Attachment #8607338 - Flags: review?(karlt) → review+
I believe the cause of the timeout was fixed with the fixes from bug 1163227 as I can't reproduce this timeout any longer. I will leave this open to see if that is indeed the case and close it in a week or so.
Component: Audio/Video → Audio/Video: Playback
Priority: -- → P5
the test starts playback, then load 6s of data wait for the various appendBuffer events to be fired and then test that it all happened before currentTime reaches .25s those webref tests are now only enabled on debug build, so much slowed down compare to a normal build. It happens often that by the time we've reached the test, over 0.25s has lapsed and the test will fail. As the test fail, we fail to reach later events and as such it fails with time out. Any changes of timing will only make things worse. Then it does some assumptions on the order at which events are fired. like bug 1148224 this is very much a test on how chrome behaves. Additionally we can read in the comment: "// endOfStream can change duration downwards slightly. // Allow for one more 'durationchange' event only in this case. " When changing the duration to 0.5, the media element actually contains from from 0.03 to 0.53, the last video frames starts prior 0.5, so per spec we remove *after* this frame, so when calling endOfStream() the mediasource duration will be extended to 0.53 As such the following test: assert_true(currentDuration > 0 && currentDuration < newDuration, 'adjusted duration') will always be false. All this is because chrome adjust and fake the samples timestamps so that they always start at 0, here they start at 0.03. I will lodge a bug against the webref test, and will disable this test in the mean time. As I know that bug 1245463 triggers the timeout much more often seeing that we are now blocking for an appendBuffer to complete, I will disable this test for now.
oh only realised that there was a patch to disable that didn't get committed. will do now, but for all platforms
The leave-open keyword is there and there is no activity for 6 months. :jya, maybe it's time to close this bug?
Flags: needinfo?(jyavenard)
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jyavenard)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: