It seems that CloudXR 3.2 has higher chance to have problems upon launch.
There are occasions where I got connected to the server but cannot see anything from the screen.
In log, normal logs look like:
05-18 11:39:26.505 13212 13290 V CloudXR : Input stream connected.
05-18 11:39:26.505 13212 13290 V CloudXR : Streaming started in HEVC.
05-18 11:39:26.506 13212 13376 V CloudXR : Eye0 processing thread started.
05-18 11:39:26.506 13212 13377 V CloudXR : Eye1 processing thread started.
05-18 11:39:26.506 13212 13290 V CloudXR : Receiver created for server: 192.168.50.133
When the problem occus, logs look like:
05-18 11:39:52.779 13434 13498 V CloudXR : Input stream connected.
05-18 11:39:52.779 13434 13498 V CloudXR : Streaming started in HEVC.
05-18 11:39:52.780 13434 13588 V CloudXR : Eye0 processing thread started.
05-18 11:39:52.780 13434 13588 V CloudXR : Eye0 processing thread shutdown.
05-18 11:39:52.780 13434 13590 V CloudXR : Worker thread started.
05-18 11:39:52.780 13434 13498 V CloudXR : Receiver created for server: 192.168.50.133
Both created a receiver connected to the server, but the later’s Eye0 processing thread shutdown for unknown reasons and is not starting Eye1 processing thread. Thus I cannot latch frame successfully since no eye threads are up.
I’d probably recommend using -v to generate verbose logs, and then in a failing case quit the app, go find the client and server logs for that run, and post them for further review.
I can’t say that I’ve personally ever seen this. Any chance you are using RDP to the server in the failing case? That is known to impact capture. Other than that, maybe logs will point us towards potential issue.
We get an issue similar to this, it might be correlated. If you take your headset off and put it on again, sometimes it shows a black screen and the logs show something failed during the re-creation of the swap chain textures inside the CloudXR library. We had something similar in our older 3.0 builds as well but the repro was seemingly random. If you enter / leave the play tracking space multiple times (random number of times), the app would simply crash during the resume function when it’s recreating the swap chains. Overall 3.2 seems actually less stable than 3.0 for us and we’re hoping if there are any hotfixes coming soon then we’ll be able to adopt 3.2 for the higher refresh rates and other features.
Again, not something I’ve seen generally here. client+server+logcat logs right after a crash would be helpful to try to understand the cause. Explicit repro steps would also be useful, since if we can get it to happen here, we can more directly debug.
There’s still some lifecycle work needed on both Focus and Quest. Focus in a sense hard-pauses your process, so you have limited opportunity to clean up and prep for later resume. The lifecycles are also slightly different across vendors, let alone can change in subtle ways across versions of the OS. And what happens to the app when you ‘go home’ is also quite different between the platforms. This all makes it difficult to have a one-size-fits-all solution.
But I think we’re getting there. 3.2 actually for me (having worked on the lifecycle problems) is WAY better for the most part. There are still some issue to root out, that is for sure.
The more logs and details you can provide, the better the chance we can investigate and fix whatever the problem is.
Thank you. I took me some time to get back to this problem.
I’m running on an Android 12 device and Android 12 doesn’t give WRITE_EXTERNAL_STORAGE permission so it’s a bit awkward for me to have CloudXR logs at this moment.
Is there anyway to output CloudXR logs via logcat?
Ok, so I just went a bit deeper into this problem, and got myself into a very awkward situation…
When this happens (processing thread shutdown), the connection is established and the server graphics will respond to my pose correctly. But there’s nothing I can see in my glasses, and it keeps that way. Latch frame won’t succeed.
I was running my client with Nreal’s glasses on an OnePlus 9 with Android 12. Thus I cannot authorize “android.permission.WRITE_EXTERNAL_STORAGE”, and cannot obtain any logs from verbose, local events, stream events, or qos generated by CloudXR SDK itself, as it only writes into /sdcard/CloudXR/logs, which is prohibited by Android 12.
So I found myself another phone with Android 10, then I found I had to lower target SDK and related versions to 29 to authorize the correct permissions. When I can finally generate these logs from my client, I can no longer reproduce this problem… My client is really robust on Android 10 somehow…
It looks like this problem has something to do with Android 12 at least.
It would be helpful if CloudXR logs can be generated at custom locations, such as inside the application’s data directory.