YT MSE tests need more than current default timeout on Android K OS |
|||||
Issue descriptionVersion: 51.0.2687.0 OS: Android M These tests fail with spitzer off. So it has lower priority. Half of these tests fail on Android L as well. (see 568686 that track Android L) since our goal is Android has better user experience with spitzer, we may want to fix these API, but lower priority. failed tests on Webm: 14 ~ 20, 23, 24, 29, 30, 32 ~ 54 failed tests on mp4: 14 ~ 20, 23, 24, 29, 30, 32 ~ 54 What steps will reproduce the problem? (1) navigate to yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/tip.html (2) click Run All What is the expected output? all tests pass What do you see instead? half tests failed
,
Mar 31 2016
yiningc@, thanks for filing this. When you repro, are you keeping to the default test timeout, or are you increasing it? If using the default, can you try with a much larger value and report back?
,
Apr 5 2016
matt, that's good information. After set timeout to 60000, all tests pass (except #51 which is tracked in cr/574514). can we resolve this bug as is OR should we ask thom to update default timeout to 60000?
,
Apr 5 2016
Thanks for checking again with longer timeout. Over to tdedecko@, since I think increasing the default timeout would help suppress such failures.
,
Apr 5 2016
Please see: http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/instructions.html You can increase the timeout by appending the param ?timeout=60000
,
Apr 5 2016
oh sorry, I just read the rest of the bug. I could increase the default but I think giving the option to specify the timeout helps resolve some of these issues. If I were to change the default would 40000 or 50000 be acceptable defaults? Or is 60000 the magic number in most cases?
,
Apr 5 2016
yiningc@: Can you see if nothing regresses at a shorter timeout on the slowest device we test with? Say, 40000 or 50000? If not, I'd say just go with 60000 to prevent spurious flakes on these slower devices.
,
Apr 5 2016
Matt, I need make a correction. It seems the failed tests on Android K now pass is NOT because of the increased timeout. All these tests pass on chrome 51.0.2693.2 magically even with the default 30000 timeout time. I also tried Android L with the same chrome build, unfortunately all the failed tests (tracked in 568686) still fail, increase timeout time to 60000 doesn't help. So there is no need to change default timeout value now. I will resolve this bug but still need investigate cr/568686 when you have time.
,
Apr 5 2016
Can you confirm on Android K run (that's now passing with default timeout) that you're using Spitzer? IIRC, Dale switched some of the logic around for this last week.
,
Apr 5 2016
Matt, I confirmed on Android K run, the spitzer is enabled. Actually, no matter spitzer is enabled or disabled (through chrome://flags, I also verified its enable/disable state on chrome://version), all MP4 and Webm tests pass in default timeout. I tried M50 on the same device, there are still some tests fail. So it does have some magic changes happen on the new dev build 51.0.2693.2.
,
Sep 6 2016
yiningc@ is this still an issue?
,
Sep 16 2016
not see this issue anymore |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by wolenetz@chromium.org
, Mar 31 2016