Closed Bug 1144199 Opened 9 years ago Closed 9 years ago

Test # 4: Bioshock Infinite video goes to infinite loading screen when resuming to play after putting computer to sleep

Categories

(Core :: Audio/Video, defect, P2)

38 Branch
x86_64
Windows 8.1
defect

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox36 --- unaffected
firefox37 --- unaffected
firefox38 + fixed
firefox39 + fixed
firefox40 --- fixed

People

(Reporter: tbrais, Assigned: kinetik)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: betabreakers-fx38)

Attachments

(2 files, 2 obsolete files)

Actual Result:
When the user selects to load the Bioshock video https://www.youtube.com/watch?v=hicBgE6XndM , puts the computer to sleep, and then selects to awake computer, and continue to watch the video; the video will enter an infinite loading state
QA Whiteboard: betabreakers-fx38
Whiteboard: betabreakers-fx38
I reproduced this on my Razerblade laptop running Windows 8.0 64-bit.
* Firefox 36.0.4 - playback resumes from sleep
* Firefox 37.0b7 - playback resumes from sleep
* Firefox 38.0a2 - video is stuck in a loading state from sleep
* Firefox 39.0a1 - 

[Tracking Requested - why for this release]: this is a regression.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #2)
> * Firefox 38.0a2 - video is stuck in a loading state from sleep
> * Firefox 39.0a1 - 

Sorry, I meant to say here that Firefox 39.0a1 displays the same behaviour as Firefox 38.0a2.
Last Good: 2015-02-19 [986e840a2979]
First Bad: 2015-02-20 [1b4c5daa7b7a]
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=986e840a2979&tochange=1b4c5daa7b7a
Tracking for 38 and 39. 
Anthony can you suggest someone to work on this? Thanks!
Flags: needinfo?(ajones)
Ralph, can you help with this bug? Thanks
Flags: needinfo?(giles)
The most likely looking changes from the regression window are the cubeb and rendering changes, e.g. bug 1134078. Kinetik, does that seem plausible to you?

Otherwise, ashughes, could you reproduce with logging enabled and attach? That will help track down where it's getting stuck.

MEDIA_LOG_SAMPLES=1 
NSPR_LOG_MODULES=MediaDecoder:5,MediaSource:5,MediaPromise:5,nsMediaElement:5,nsMediaElementEvents:5
Blocks: MSE
Flags: needinfo?(kinetik)
Flags: needinfo?(giles)
Flags: needinfo?(anthony.s.hughes)
Priority: -- → P2
Attached file bug1144199.log (obsolete) —
Here is the log you requested, Ralph.
Flags: needinfo?(anthony.s.hughes)
In a further development, after installing the latest Windows 8.1 updates I can no longer reproduce this bug. I'm doing a system restore right now to see if that makes this reproduce again. That said, if an updated Windows system cannot reproduce this then maybe the bug is moot.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #10)
> In a further development, after installing the latest Windows 8.1 updates I
> can no longer reproduce this bug. I'm doing a system restore right now to
> see if that makes this reproduce again. That said, if an updated Windows
> system cannot reproduce this then maybe the bug is moot.

Scratch that - the bug does not reproduce when I have NSPR logging enabled. Rolling back the updates the bug came back but once I turned NSPR logging on the bug disappeared.
Well I can't reproduce this bug in any build anymore on this system. In the course of trying to get the logging to work, this bug went away. If we need the logging to move forward on this I'll need to escalate this to Betabreakers.
Attached file 8829321.txt (obsolete) —
Here is the nspr log from my machine, even though it's not reproducing the bug anymore, just in case it's still useful.
Attachment #8589903 - Attachment is obsolete: true
Attached file nsprlog.txt
For some reason the log got cut off, here it is again.
Attachment #8589936 - Attachment is obsolete: true
Ralph, can you please prepare a Try server build to test the theory that bug 1134078 might be the cause? I've received approval to have Todd do some more testing and debugging for us.
Flags: needinfo?(giles)
Todd, can you please help us debug this further:

1. Check to see if the bug still reproduces using the build you tested before
2. Check to see if the bug reproduces in the latest Firefox 38: https://beta.mozilla.org/
3. Check to see if the bug reproduces in the latest Firefox Nightly: https://nightly.mozilla.org/
4. Check to see if the bug reproduces in Ralph's Try server build (when available).
5. Install all Windows updates and check the above builds continue to reproduce the bug.

If the bug still reproduces I will provide further instruction so you can generate logs for us. If the bug stops reproducing I will provide further instruction so you can narrow down the "fix" range for us.
Flags: needinfo?(tbrais)
It's possible/likely the audio thread hang prevention added in bug 1134078 (the timeout added to the WaitForMultipleObjects call) is being triggered by the sleep/wake transition.  I've pushed a potential fix to Try for testing: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1b75e6903bed

This change requires the wait to timeout multiple times in a row with no other activity before the hang prevention is triggered.  The timeout should only trigger once across a sleep/wake cycle, so if my guess about the cause is correct, this should fix the problem.
Flags: needinfo?(kinetik)
Anthony, This still occurs when using the build that I tested before (FF 38.0a2 Build ID: 20150330004006)I'm in the process of gathering 'about' files, and testing the other versions as you mentioned

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #16)
> Todd, can you please help us debug this further:
> 
> 1. Check to see if the bug still reproduces using the build you tested before
> 2. Check to see if the bug reproduces in the latest Firefox 38:
> https://beta.mozilla.org/
> 3. Check to see if the bug reproduces in the latest Firefox Nightly:
> https://nightly.mozilla.org/
> 4. Check to see if the bug reproduces in Ralph's Try server build (when
> available).
> 5. Install all Windows updates and check the above builds continue to
> reproduce the bug.
> 
> If the bug still reproduces I will provide further instruction so you can
> generate logs for us. If the bug stops reproducing I will provide further
> instruction so you can narrow down the "fix" range for us.
Flags: needinfo?(tbrais)
Reverting just the change from bug 1134078 wasn't straigtforward, so I did a build with the entire cubeb library reverted to the version we used prior to that bug landing. So there may be other issues from regression subsequent bugs. Nevertheless:

https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/rgiles@mozilla.com-1308000b1bbf/try-win32/
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/rgiles@mozilla.com-1308000b1bbf/try-win32-debug/

Use the first one for basic reproduction. The second, debug build for generating logging.
Here are the testing results for 4/10/2015: 

I was still able to reproduce Bug 1144199: Bio shock Infinite video goes to infinite loading screen when resuming playing after putting computer to sleep

This occurred on all versions of FF that were provided to me:

- Firefox 38.0a2 (Build ID: 20150330004006) *Previous build tested
- Firefox Beta 38.0 (Build ID: 20150406174117)
- Firefox Nightly 40.0a1 (Build ID: 20150410030204)

 
During testing I observed that when setting the video quality to 1080p, putting my system to sleep, and then awakening the system; the video would enter an indefinite load state. However if I changed the resolution to something lower than 1080p; the video would continue to play.
 
This issue does NOT occur on the following build:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/rgiles@mozilla.com-1308000b1bbf/try-win32/firefox-40.0a1.en-US.win32.installer.exe

I receive a 'Bad news first: This tab has crashed' error when returning to FF tab that has the Bio shock video from a sleep state' When trying to reproduce this issue with https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mgregan@mozilla.com-1b75e6903bed/try-win32/firefox-40.0a1.en-US.win32.installer.exe



Machine name: JANDICE
Operating System: Windows 8.1 64-bit (6.3, Build 9600) (9600.winblue_r8.150127-1500)
Language: English (Regional Setting: English)
System Manufacturer: Hewlett-Packard
System Model: h8-1400z
BIOS: v8.08
Processor: AMD FX(tm)-8120 Eight-Core Processor (8 CPUs), ~3.1GHz
Memory: 8192MB RAM
Available OS Memory: 7982MB RAM
Page File: 1963MB used, 6417MB available
Todd, thank you for the results.

Ralph, based on Todd's testing does this give any more evidence that bug 1134078 is the cause? Is there still benefit in having Todd generate some logs with a broken build?

Kinetik, it seems like your Try build is actually worse off for Todd.
Flags: needinfo?(kinetik)
Flags: needinfo?(giles)
Hmm, the 1080p correlation doesn't sound like cubeb, but reverting to the cubeb version prior to bug 1134078 removing the issue does. Kinetik, I think it's more likely to be yours at this point. Can you take a look and unassign if you change your mind about the cause?

Todd, I don't think logging is helpful to get at this point. Can you test Kinetik's build with e10s disabled though? There might be an interaction there causing the crash which I'd like to eliminate. Flip the pref by going to about:preferences, General, uncheck 'Enable E10S (multi-process)', and restart Firefox.
Assignee: nobody → kinetik
Flags: needinfo?(giles) → needinfo?(tbrais)
Ralph - 
I receive an 'Nightly has stopped working' dialogue box after disabling 'E105 (multi-process)
(In reply to Ralph Giles (:rillian) from comment #23)
> Hmm, the 1080p correlation doesn't sound like cubeb, but reverting to the
> cubeb version prior to bug 1134078 removing the issue does. Kinetik, I think
> it's more likely to be yours at this point. Can you take a look and unassign
> if you change your mind about the cause?
> 
> Todd, I don't think logging is helpful to get at this point. Can you test
> Kinetik's build with e10s disabled though? There might be an interaction
> there causing the crash which I'd like to eliminate. Flip the pref by going
> to about:preferences, General, uncheck 'Enable E10S (multi-process)', and
> restart Firefox.
Flags: needinfo?(tbrais)
There was a dumb bug in my potential fix: I accidentally moved the break inside the timeout counter condition, so it was falling through to the unhandled case and asserting -- sorry about wasting your time with that build.  Fixed build should be available via this Try push soon: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ce811fc687b7
Flags: needinfo?(kinetik)
Todd, would you mind retesting with the build in http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mgregan@mozilla.com-ce811fc687b7/try-win32/ please?
Flags: needinfo?(tbrais)
Testing in progress. Will give an update shortly

(In reply to Matthew Gregan [:kinetik] from comment #26)
> Todd, would you mind retesting with the build in
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mgregan@mozilla.
> com-ce811fc687b7/try-win32/ please?
Flags: needinfo?(tbrais)
Matthew; This issue does NOT occur on the build that you provided
> 
> (In reply to Matthew Gregan [:kinetik] from comment #26)
> > Todd, would you mind retesting with the build in
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mgregan@mozilla.
> > com-ce811fc687b7/try-win32/ please?
Thanks for testing the build and confirming that it solves the problem, Todd.  I'll prepare a patch for review.
Status: NEW → ASSIGNED
Flags: needinfo?(ajones)
Attachment #8592007 - Flags: review?(padenot) → review+
Blocks: 1134078
Comment on attachment 8592007 [details] [diff] [review]
bug1144199_v0.patch

Approval Request Comment
[Feature/regressing bug #]: bug 1134078
[User impact if declined]: no audio and/or broken media playback after system sleep/hibernate
[Describe test coverage new/current, TreeHerder]: manually tested
[Risks and why]: low, extends existing timeout mechanism with a simple change
[String/UUID change made/needed]: none
Attachment #8592007 - Flags: approval-mozilla-release?
Attachment #8592007 - Flags: approval-mozilla-beta?
https://hg.mozilla.org/mozilla-central/rev/74903317d80d
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Comment on attachment 8592007 [details] [diff] [review]
bug1144199_v0.patch

I guess we want aurora & beta (not beta & release)

Should be in 38 beta 5
Attachment #8592007 - Flags: approval-mozilla-release?
Attachment #8592007 - Flags: approval-mozilla-release+
Attachment #8592007 - Flags: approval-mozilla-beta?
Attachment #8592007 - Flags: approval-mozilla-beta+
Todd, one last thing - can you check the fixed builds when they come out?

Firefox 40.0a1 should have the fix tomorrow (April 16) [https://nightly.mozilla.org]
Firefox 39.0a2 should have the fix tomorrow (April 16) [https://aurora.mozilla.org]
Firefox 38.0b5 should have the fix on Friday (April 17) [https://beta.mozilla.org]
Flags: needinfo?(tbrais)
(In reply to Sylvestre Ledru [:sylvestre] from comment #35)
> I guess we want aurora & beta (not beta & release)

Oops, yes, sorry - wrong flags!
Anthony,
 This issue does not occur when testing the following builds:
Firefox 40.0a1 should have the fix tomorrow (April 16) [https://nightly.mozilla.org]
Firefox 39.0a2 should have the fix tomorrow (April 16) [https://aurora.mozilla.org]
I will test Firefox 38.0b5 tomorrow (when it comes in)

(In reply to Anthony Hughes, QA Mentor (:ashughes) [Away April 16-26] from comment #38)
> Todd, one last thing - can you check the fixed builds when they come out?
> 
> Firefox 40.0a1 should have the fix tomorrow (April 16)
> [https://nightly.mozilla.org]
> Firefox 39.0a2 should have the fix tomorrow (April 16)
> [https://aurora.mozilla.org]
> Firefox 38.0b5 should have the fix on Friday (April 17)
> [https://beta.mozilla.org]
Flags: needinfo?(tbrais)
Anthony,
As of 4/17/2015: This bug still occurs on Firefox 38.0b5 [https://beta.mozilla.org]

Application Basics
------------------

Name: Firefox
Version: 38.0
Build ID: 20150413143743
Update Channel: beta
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Multiprocess Windows: 0/1 (default: false)

Crash Reports for the Last 3 Days
---------------------------------

All Crash Reports

Extensions
----------

Graphics
--------

Adapter Description: AMD Radeon HD 7670
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 1024
Device ID: 0x675b
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16581)
Driver Date: 2-19-2013
Driver Version: 9.12.2.3000
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 6888103c
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 7670 Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Important Modified Preferences
------------------------------

browser.cache.disk.capacity: 358400
browser.cache.disk.smart_size.first_run: false
browser.cache.frecency_experiment: 4
browser.download.importedFromSqlite: true
browser.places.smartBookmarksVersion: 7
browser.startup.homepage_override.buildID: 20150413143743
browser.startup.homepage_override.mstone: 38.0
dom.mozApps.used: true
extensions.lastAppVersion: 38.0
media.gmp-eme-adobe.lastUpdate: 1429291015
media.gmp-eme-adobe.version: 8
media.gmp-gmpopenh264.lastUpdate: 1429291015
media.gmp-gmpopenh264.version: 1.3
media.gmp-manager.buildID: 20150413143743
media.gmp-manager.lastCheck: 1429291014
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
privacy.sanitize.migrateFx3Prefs: true

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.10.8
Version in use: 4.10.8

NSS
Expected minimum version: 3.18 Basic ECC
Version in use: 3.18 Basic ECC

NSSSMIME
Expected minimum version: 3.18 Basic ECC
Version in use: 3.18 Basic ECC

NSSSSL
Expected minimum version: 3.18 Basic ECC
Version in use: 3.18 Basic ECC

NSSUTIL
Expected minimum version: 3.18
Version in use: 3.18

Experimental Features
---------------------
Build ID: 20150413143743 (it is a date)
I am pretty sure it is beta 4 as we built beta 5 yesterday.
We are going to push beta 5 in an hour max. Could you update and try then?
Flags: needinfo?(tbrais)
So as of 2:00pm (PST) a couple of things are happening when testing the build on URL here.

When setting up a test environment with the following three videos (as seen on the FF 38 wiki) 
•	https://www.youtube.com/watch?v=Jp59FElhOTw (set to 1080p)
•	https://www.youtube.com/watch?v=79ImZE0K7xc (set to 1080p)
•	https://www.youtube.com/watch?v=7SRTEXSpcyI (set to 1080p)

Loading the Bio Shock video (URL used for this bug) in 1080p; the video will not load (displays infinite loading loop). (Bug 1144237 - During Test 3 (Stress test) multiple videos buffer forever or just stop playing https://bugzilla.mozilla.org/show_bug.cgi?id=1144237)

If I close the initial three video links (as seen on the FF 38 wiki) the Bio shock video will properly play in the 1080p resolution. 
 After awakening my system from sleep mode; the video will continue to play without any issues



(In reply to Sylvestre Ledru [:sylvestre] from comment #42)
> Build ID: 20150413143743 (it is a date)
> I am pretty sure it is beta 4 as we built beta 5 yesterday.
> We are going to push beta 5 in an hour max. Could you update and try then?
Flags: needinfo?(tbrais)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: