Oculus client shutdowns when the app loses focus

gustavo.quiroz · July 20, 2021, 1:19pm

Hi,

We noticed an issue in the CloudXR Oculus client, when the app loses focus for a couple of seconds (either when the headset goes to sleep, the power button is pressed or the user leaves the guardian area), the app shuts down.

After the headset awakes the app is already closed and either the user is back in the lobby or in a black screen with the oculus menu enabled.

We noticed the issue happening in v2.0 but it is also present in v3.0.

The following logs were generated in both versions by leaving the guardian for 3 to 5 seconds, they also contain logs from logcat.

CloudXR logs.zip (57.2 KB)

Thanks in advance.

wrice · July 21, 2021, 7:25pm

Hi,

What game/application is running on the server side when you experience the client shutdowns?

-Will

gustavo.quiroz · July 21, 2021, 9:59pm

Hi, thanks for the reply.

The issue occurs regardless of the executed application, it even happens just with SteamVR.

We are building an enterprise solution that enables the upload of your VR catalog to the cloud and execute them on demand via streaming, due to the nature of this product I’m able to test it with multiple applications (tested with at least 6 different applications).

wrice · July 28, 2021, 7:23pm

Hi,

Just to clarify is this a Quest 2 or a Quest 1?

-Will

gustavo.quiroz · July 29, 2021, 8:53am

Hi,

It actually happens in both, you can test it by using the sample CloudXR apk for Oculus Quest (any from v2.0 to v3.0) and simply leaving the Guardian area and coming back to it when the client is already streaming from the server.

wrice · July 29, 2021, 9:00am

Hi,

I was unable to replicate this on the Quest 1. I tested leaving the guardian, sleeping the headset, and simply taking the headset off. I left it in these sleep modes for about 5 minutes and was able to resume from where I left off. Based on your logs, it looks like you are losing network connection to the server when the headset sleeps.

In the latest version of the Oculus software, they fixed a “wifi degradation issue”. Some users had been reporting that when their headset went to sleep, they would lose wifi, especially when using a 5ghz wifi network. If you were hitting this issue, I can see that causing your client application issues. Could you try picking up the latest update (v31.0) for your headsets and trying again?

-Will

marc24 · September 7, 2021, 12:47am

Hi Will,

We are noticing a similar issue, and looking at the Android logs, it appears we are getting a crash in the c++ side of the app when the stream is being shut down in the pause function. This only started for us when we updated to 3.0. The shutdown looks normal in the logs up until the last bit where it’s destroying the receiver:

I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=1/0,940/305MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1555MHz,Free=2894MB,PLS=0,Temp=26.7C/0.0C,TW=4.14ms,App=2.30ms,GD=0.29ms,CPU&GPU=6.06ms,LCnt=1,GPU%=0.51,CPU%=0.24(W0.26),DSF=1.00
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=1/0,940/305MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1555MHz,Free=2890MB,PLS=0,Temp=26.7C/0.0C,TW=4.13ms,App=2.31ms,GD=0.62ms,CPU&GPU=5.87ms,LCnt=1,GPU%=0.54,CPU%=0.30(W0.33),DSF=1.00
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,710/305MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1353MHz,Free=2889MB,PLS=0,Temp=26.7C/0.0C,TW=4.11ms,App=2.32ms,GD=0.31ms,CPU&GPU=5.28ms,LCnt=1,GPU%=0.52,CPU%=0.31(W0.55),DSF=1.00
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,710/305MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1353MHz,Free=2889MB,PLS=0,Temp=26.7C/0.0C,TW=4.11ms,App=2.33ms,GD=0.76ms,CPU&GPU=5.48ms,LCnt=1,GPU%=0.57,CPU%=0.30(W0.39),DSF=1.00
I/Telemetry: App memory usage: PSS=285MB DalvikPSS=1 MB
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,710/305MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1353MHz,Free=2891MB,PLS=0,Temp=26.7C/0.0C,TW=4.13ms,App=2.34ms,GD=0.29ms,CPU&GPU=5.74ms,LCnt=1,GPU%=0.51,CPU%=0.28(W0.43),DSF=1.00
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,710/305MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1555MHz,Free=2887MB,PLS=0,Temp=26.7C/0.0C,TW=4.15ms,App=2.30ms,GD=0.62ms,CPU&GPU=5.91ms,LCnt=1,GPU%=0.54,CPU%=0.32(W0.39),DSF=1.00
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,710/305MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1555MHz,Free=2887MB,PLS=0,Temp=26.7C/0.0C,TW=4.16ms,App=2.37ms,GD=0.34ms,CPU&GPU=6.25ms,LCnt=1,GPU%=0.53,CPU%=0.27(W0.32),DSF=1.00
V/main: In AppPaused() method
V/message: In AppPaused() method
E/main: shutting down playbackStream…
D/AAudio: AAudioStream_requestStop(s#1) called
D/AudioTrack: stop(944): called with 1071364 frames delivered
D/: PlayerBase::stop() from IPlayer
D/AAudio: AAudioStream_close(s#1) called ---------------
V/threaded_app: WindowFocusChanged: 0x70c9b49b80 – 0
D/FA: Event not sent since app measurement is disabled
V/FA: Using local app measurement service
V/FA: Activity paused, time: 281130609
V/FA: Local AppMeasurementService is starting up
V/FA: Bound to IMeasurementService interface
V/FA: Connected to service
V/FA: Processing queued up service tasks: 1
D/AAudio: AAudioStream_close(s#1) returned 0 ---------
E/main: shutting down recordingStream
D/AAudio: AAudioStream_requestStop(s#2) called
D/: PlayerBase::stop() from IPlayer
D/AAudio: AAudioStream_close(s#2) called ---------------
D/: PlayerBase::~PlayerBase()
D/AAudio: AAudioStream_close(s#2) returned 0 ---------
E/main: shutting down receiver
V/CloudXR: Closing the CloudXR log.
Displayed 916 frames over 21.34 seconds (42.9 FPS).
V/CloudXR: Worker thread shutdown.
V/CloudXR: CloudXR destroy receiver
Input stream disconnected.
Audio Send stream disconnected.
V/CloudXR: Eye1 processing thread shutdown.
V/CloudXR: Eye0 processing thread shutdown.
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,1171/525MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=2092MHz,Free=2883MB,PLS=0,Temp=26.7C/0.0C,TW=4.16ms,App=2.37ms,GD=0.34ms,CPU&GPU=6.25ms,LCnt=1,GPU%=0.53,CPU%=0.27(W0.32),DSF=1.00
V/threaded_app: NativeWindowDestroyed: 0x70c9b49b80 – 0x6fe1588010
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,1171/525MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=2092MHz,Free=2882MB,PLS=0,Temp=26.7C/0.0C,TW=4.16ms,App=2.37ms,GD=0.34ms,CPU&GPU=6.25ms,LCnt=1,GPU%=0.53,CPU%=0.27(W0.32),DSF=1.00
V/CloudXR: Streamer shutdown.
V/CloudXR: Mediacodec: Decoder thread done.
D/SurfaceUtils: disconnecting from surface 0x6fe1674010, reason disconnectFromSurface
V/CloudXR: Mediacodec: Decoder thread done.
D/SurfaceUtils: disconnecting from surface 0x6fe16be010, reason disconnectFromSurface
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,1171/525MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1353MHz,Free=2869MB,PLS=0,Temp=26.7C/0.0C,TW=4.16ms,App=2.37ms,GD=0.34ms,CPU&GPU=6.25ms,LCnt=1,GPU%=0.53,CPU%=0.27(W0.32),DSF=1.00
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x550779d5476cfa in tid 27243 (main), pid 27156 (utosphere.devel)
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,1171/525MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1804MHz,Free=2858MB,PLS=0,Temp=26.7C/0.0C,TW=4.16ms,App=2.37ms,GD=0.34ms,CPU&GPU=6.25ms,LCnt=1,GPU%=0.53,CPU%=0.27(W0.32),DSF=1.00
I/VrApi: FPS=72/72,Prd=34ms,Tear=0,Early=0,Stale=0,VSnc=1,Lat=0,Fov=0,CPU4/GPU=0/0,1171/525MHz,OC=FF,TA=0/0/0,SP=N/N/N,Mem=1804MHz,Free=2848MB,PLS=0,Temp=26.7C/0.0C,TW=4.16ms,App=2.37ms,GD=0.34ms,CPU&GPU=6.25ms,LCnt=1,GPU%=0.53,CPU%=0.27(W0.32),DSF=1.00

It doesn’t happen every time, so it seems like a race condition in the client shutdown. We are also seeing this with the August hot-fix version. And we’re running v32 of the Quest 2 software.

Not sure if this is the same issue, but the behavior is the same to the user. Is there more information I could provide that would be useful?

/marc

tegradave · September 20, 2021, 3:07pm

I’m hopeful this will be resolved in the next release. It is certainly much improved, but as always there might be corner cases we didn’t catch yet.

marc24 · November 22, 2021, 7:45pm

@tegradave Do you believe that the 3.1 release helps this condition?

tegradave · November 22, 2021, 8:25pm

I’ve not seen the crash or original issue. But there’s a lot of improvements to the oculus sample, a lot of changes to lifecycle handling, so hoping this is better now. Let me know if you still run into issues and repro steps.

gustavo.quiroz · January 4, 2022, 1:23pm

Hi everyone, a quick update, turns out that CloudXR has nothing to do with the issue, the real problem was that the Activity where CloudXR is loaded was not running in the default process, we made this change so it could co-exist with a Unity player.

I also discovered that any activity that does not run in the default process kills the app as soon as the app loses focus while given activity is in the foreground (i.e., the hmd loses track of the guardian, the hmd is out of the guardian, the hmd goes to sleep or the power button is pressed).

tegradave · January 5, 2022, 5:47pm

yes, we’re looking to improve the current lifecycle handling in a future update. 3.1 does have some improvements, so that pause cases should not cause the entire system to shut down. note that oculus and wave clients are not necessarily in parity when it comes to lifecycle, as they implement platform support completely differently.