Hello, I'm having trouble with remote rendering after the latest updates to the Magic Leap Hub.
Windows 10 21H2
Magic Leap OS - 1.3.0-dev2
Magic Leap Remote Rendering 1.2.88
The only message I now get on the headset in the remoting app is "Waiting for one of the configured hosts to become available" with the IP of the host showing up in the list. My OpenXR app creates the XR session but nothing is displayed on the ML2. The Device Stream and Advanced Capture are working.
The exact same configuration worked with the previous versions of the remoting app, the ML2 OS and the Hub; however, the latest hub no longer appears to work with older versions of the remote rendering, remote rendering 1.2.88 doesn't work with the previous non-dev version of the ML2 OS and it doesn't look there is a way to roll back everything to a working state.
Could you please advise how to debug this further?
Are you able to send us the output of powershell.exe -ExecutionPolicy Bypass -File "C:\Program Files\Magic Leap Remote Rendering\DebuggerScript.ps1"
contents of $env:APPDATA/MagicLeap/Windrunner/logs/windrunner.log
If you need, I can send a private way to send us the logs. Thank you.
I'd prefer to send the logs in a private way because of the network info, but the summary from what I see is that pinging the ML device succeeds, Remote Viewer is started successfully and the Windrunner service is running and waiting without any errors.
I had an older copy of the ML hub on a different computer, so I copied that over and downgraded the ML2 remoting app and the remote rendering service to version 1.1.73. That worked with everything else in the setup being exactly the same.
Do you have any suggestions for things to try? I did a factory reset of the device and a clean reinstall of the ML Hub, but I'm still seeing "Waiting for one of the configured hosts to become available".
Hi @kaloian.petkov apologies for the delay. Previous versions of Remote Rendering paired over ADB, now the current version uses port TCP/50052. It may be an issue of blocked UDP/50051, TCP/50052 on the network.
Also we took a look at the logs and it shows the windrunner as started and waiting for the client to connect. Have you launched the client through the Magic Leap Hub? And is the Hub allowing you to attempt pairing, or erroring beforehand?
If you have launched the client through the Hub, please send diagnostic logs: Home > Save Diagnostic Logs...
Hi @kdowney, I'm running the ML2 remoting on our enterprise-managed workstations, but connected to our lab's self-managed router. I tried opening those ports on the Windows firewall, but it didn't help. Running the remoting on the same network and the same headset, but from a non-managed computer works fine.
From within ML Hub, the Wifi device bridge works and I'm able to pair with the headset from the 'Remote Render (Preview)' tile. Hitting 'Start' launches the remote rendering app on the headset. Everything looks like it should be working, but the Windrunner service and the HMD just can't talk to each other.
I've sent the requested logs over email. There are many socket errors, but at this point I'm not sure what needs to be changed in our managed environment to make this work. Is there any way to configure the remoting service to use the old communication interfaces? Those seemed to work ok.
Hi @kaloian.petkov, Our remote rendering team took a look at the logs you sent. The issue is:
error 104: Connection reset by peer
07-12 21:05:23.047 10105 25148 25536 V LuminRemoteTransport: [HealthCheckClient] Failed to receive data from 192.168.17.148:50051. Socket error=104 07-12 21:05:23.047 10105 25148 25170 W LuminRemoteTransport: [HealthCheckClient] Failed to find a healthy service within the timeout: 5 seconds 07-12 21:05:23.047 10105 25148 25170 E com.magicleap.remote_viewer_app: Failed to find available host from 192.168.17.148:50051;
This points to a router issue.
In terms of next steps, we'd recommend talking to your network admin about the error. You can also connect your device via USB-C to your computer to see if that is successful, which would nail down the issue to the router.
The remote rendering is broken again in our enterprise environment with the current version of MLHub from 8/24/2023, the 1.5.49 version of the remote rendering and the 1.4.0-dev1 OS build. It's the same symptoms as before. Reverting everything to the previous versions fixes the issue.