CloudXR needs a good internet connection (under 30ms latency), otherwise, after some lags and dropped frames, the cloudXR library internally disconnects the stream, and below log is shown,
[13:29:24.491] I (ReceiverXR) [PERF] DISCARDED: StreamIdx 1, [FrameNum:6656] [Network Dropped this frame]
[13:29:24.491] I (ReceiverXR) [PERF] DISCARDED: StreamIdx 1, [FrameNum:6657] [Network Dropped this frame]
[13:29:32.599] I (CXRViewController) Origin: [-0.001311, -0.849100, -0.625309]
[13:29:33.475] I (netStreamClient) Input stream disconnected.
After this state, it seems there is no way to destroy the session or start the VR session again,
@nidhishree.hp , @simon27 : Have you noticed this behavior on any other platform? I realize you may not be doing much testing on others, but I wanted to see if it has been observed to be a wider problem or something particular to the iOS support stack.
From my side I’ve only really been testing on iOS.
I did spend a bit of time yesterday trying to reproduce to see if I get could get more useful stack traces etc. Just by walking away from the router I managed to get various frame drops, and then continuing to walk away does disconnect the stream. This was using 4.0.1 iOS SDK and server. However those tests did always call the status update callback with an error, and didn’t then deadlock in cxrDestroyReceiver. I’ll post here or on my other thread if I do manage to get a stack trace of the deadlock.
One interesting observation from yesterday was after those disconnections, trying to reconnect when back in the same room as the router did fail to reconnect immediately (handshake failed). I discovered that actually toggling Wi-Fi on and off on the device would allow the reconnection to succeed, so I thought perhaps the TCP socket was still in some weird half-connected state. It even persisted across a SteamVR restart and an iOS app restart if memory serves, so might be something deep in the iOS network stack…