Closed Bug 814533 Opened 12 years ago Closed 8 years ago

Intermittent test_playback_rate.html | We are effectively slowing down playback. (10.348, 9.287981) for big.wav-0 | We are effectively slowing down playback. (4.922, 4) for sound.ogg-1

Categories

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

All
Windows 7
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: RyanVM, Assigned: padenot)

References

Details

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

https://tbpl.mozilla.org/php/getParsedLog.php?id=17287542&tree=Mozilla-Inbound

Rev3 WINNT 6.1 mozilla-inbound debug test mochitest-1 on 2012-11-22 12:40:30 PST for push 78ed9104dadd
slave: talos-r3-w7-046

130408 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_playback_rate.html | We are effectively slowing down playback. (10.348, 9.287981) for big.wav-0

Seeing a bunch of the following assertion too, not sure if it's related.

[Parent 3176] ###!!! ASSERTION: Should have positive clock time.: 'clock_time >= mStartTime', file e:/builds/moz2_slave/m-in-w32-dbg/build/content/media/MediaDecoderStateMachine.cpp, line 2277
Paul, any thoughts on what's causing this? Does the playback rate patch need to be backed out or is there a problem with the test?
Summary: Intermittent test_playback_rate.html | We are effectively slowing down playback. (10.348, 9.287981) for big.wav-0 → Intermittent test_playback_rate.html | We are effectively slowing down playback. (10.348, 9.287981) for big.wav-0 | We are effectively slowing down playback. (4.922, 4) for sound.ogg-1
Please can you look at this, it's fairly frequent now and I'd like to avoid backing out bug 495040 if possible :-)
Flags: needinfo?(paul)
Sure, I'll have a look today.
Flags: needinfo?(paul)
Assignee: nobody → paul
I believe this is related to the fact the test is close the start of the AudioStream. Either the stream is taking too long to initialize, or something else. This is backed by the fact the exact same test never fails when not close to the creation of the media element.

Indeed, in this test, we test the |playbackRate| property, then seek to the beginning, and test the |defaultPlaybackRate| property in the same fashion. The only difference is that we test the |playBackRate| property first. Also, this test never fails for video-only media.

I'm going to investigate some more.
(In reply to Paul ADENOT (:padenot) from comment #47)
> I believe this is related to the fact the test is close the start of the
> AudioStream. Either the stream is taking too long to initialize, or
> something else. This is backed by the fact the exact same test never fails
> when not close to the creation of the media element.
> 
> Indeed, in this test, we test the |playbackRate| property, then seek to the
> beginning, and test the |defaultPlaybackRate| property in the same fashion.
> The only difference is that we test the |playBackRate| property first. Also,
> this test never fails for video-only media.
> 
> I'm going to investigate some more.

Thank you for digging into this. Do you know when you might be able to continue looking at it? Just trying to work out whether it should be disabled in the meantime (top-orange).
My patch in bug 815107 may help this, I will land it today, watch this space...
Test disabled on Linux for too many intermittent failures:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f34aa04ebe5f
Whiteboard: [test disabled on Linux][leave open]
test_playback_rate.html and test_seek.html disabled on all platforms.
https://hg.mozilla.org/integration/mozilla-inbound/rev/81cae114022a
Whiteboard: [test disabled on Linux][leave open] → [test disabled][leave open]
Depends on: 1020538
Blocks: 1022453
Component: Audio/Video → Audio/Video: Playback
P5
Keywords: leave-open
Priority: -- → P5
Whiteboard: [test disabled][leave open] → [test disabled]
test_playback_rate.html has been re-enabled, and is behaving fine. Closing this.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.