Quest 2 and ADB stopped working
Hello! I've been using MQDH with Quest2 for almost a year now and they used to work perfectly fine, but since a few days ago, every time I connect my Quest 2 via Link Cable, it is detected and shown as below: However, if I try to issue any command whatsoever, be it a push, install, reconnect, etc, it turns offline. This can be seen by simply opening the Meta Quest Developer Hub. It initially appears as following: But as soon as one of those commands "finishes" (they always fail), this is the screen I'm left with. I have tried issuing `adb reconnect offline`, which simply makes the device completely vanish from the devices list. Needing a reboot of the device (and a unplug/plug of the USB cable) for it to reappear. I have tried deleting the adb keys and re-authorizing; rebooting the adb server; disabling and re-enabling the developer mode; factory resetting the Quest 2; disabling Oculus Air Link; changing which adb version to use; clean reinstall of Windows; all above with no other program running on PC, to no avail. Any help would be greatly appreciated. Maybe it was something in the last update? I can't find a way to rollback and test. INFOS Headset System Version: 49068160412800150 Version: 47.0.0.282.341.428237303 Runtime Version: 47.0.0.282.341.428237138 OS Version: user-49068160412800150 No lock pattern Oculus Android App Version: 198.0.0.4.103 MQDH Version 3.1.1 ADB Version 1.0.40 4986621 OS Windows 10 Pro 22H2 Build: 19045.2486MQDH Record not working
When you press the record button in MQDH 4.9, 5.0.0, 5.0.1 it does nothing. I've also had a soft lock (was unable to save or get out of the window) when attempting to change the record settings in 5.0.1 though this has only happened once. When I revert back to MQDH 4.8 the record feature works fine. Device I'm running has OS 71 installed. CheersVoice SDK Dictation Not Working in Unity 2023.2+
I upgraded my project to Unity 6 from Unity 2022 LTS. Here's my current setup: Unity 6000.0.27f1 Meta XR Core SDK 69.0.1 Meta XR Interaction SDK Essentials 69.0.1 Meta XR Voice SDK 69.0.0 With this setup, the Core SDK requires the use of GameActivity, but the Voice SDK's dictation functionality requires Activity. As a result, dictation cannot be executed on Unity 2023.2+. This is an error on Quest 3. Is this a known issue? Or is there a possible workaround? Here’s a related information for reference: https://communityforums.atmeta.com/t5/Unity-Development/Important-Unity-6-information/td-p/1252153 https://discussions.unity.com/t/voice-sdk-crash-on-activate-meta-quest-3/935246
[RESOLVED] Building Blocks (v65): Controller Tracking visuals for Quest3 are not wired correctly
Hi, after using Building Blocks in Unity to set up controller tracking I realized, that the visuals for the Quest Plus controllers are not wired up correctly. Pls see the attached screenshots. It's simple to solve, but annoying to do manually every time. 😑 br, Max Problem - Left Controller: Problem - Right Controller: Solution - Left Controller: Solution - Right Controller:
Error While Processing APK/OBB Files During Quest App Upload
I'm encountering an issue while uploading a build for my Quest app. The build includes an APK and OBB file, and I’m using the latest version of the Oculus CLI (v1.103.0.000001). The validation passes successfully, but during the processing of the APK file, I receive the following error message: "Sorry, we encountered a problem while processing the file that you uploaded. Please try again later." :cross_mark: ERROR: Sorry, we encountered a problem while processing the file that you uploaded. Please try again later. 2024-09-20T08:38:58.390Z [ERROR] Server log: {"app_id":7362585187111727,"client":"ODH","log_level":"ERROR","event_name":"USER_ERROR","stack_trace":"UserVisibleError: Sorry, we encountered a problem while processing the file that you uploaded. Please try again later.\n at Object.y [as genProcessBinaries] (C:\\snapshot\\D_Zfull-fbsource\\edenfs\\redirections\\arvr\\js\\temp\\build-ovr-platform-util\\lib\\ovr_platform_util.js)\n at runMicrotasks (<anonymous>)\n at processTicksAndRejections (node:internal/process/task_queues:96:5)\n at async C:\\snapshot\\D_Zfull-fbsource\\edenfs\\redirections\\arvr\\js\\temp\\build-ovr-platform-util\\lib\\ovr_platform_util.js\n at async C:\\snapshot\\D_Zfull-fbsource\\edenfs\\redirections\\arvr\\js\\temp\\build-ovr-platform-util\\lib\\ovr_platform_util.js","extra":"{\"error\":\"Sorry, we encountered a problem while processing the file that you uploaded. Please try again later.\",\"os\":\"{\\\"platform\\\":\\\"win32\\\",\\\"arch\\\":\\\"x64\\\",\\\"type\\\":\\\"Windows_NT\\\"}\",\"cli_version\":\"1.103.0.000001\",\"compatibility_version\":2,\"session_id\":\"7362585187111727_2024-09-20T08:28:27.912Z\",\"command\":\"upload-quest-build\",\"app_id\":7362585187111727,\"platform\":\"ANDROID_6DOF\"}","platform":"ANDROID_6DOF","cli_version":"1.103.0.000001","session_id":"7362585187111727_2024-09-20T08:28:27.912Z","binary_id":"","duration":null,"is_patch_upload":0,"duration_since_session_start":630477}" System Info: OS: Windows 10 x64 CLI Version: 1.103.0.000001 Has anyone encountered a similar issue? We do have a builds that were uploaded yesterday and are fine. Could it be related to the Meta platform’s processing?
NavMesh not recognised in IL2CPP builds
We have recently run into some problems with navigation in a Quest 2/3 project. Navmesh agents which functioned perfectly in the editor were not working in our test builds for android. After some testing we've learned that when building for Windows or Android, if the Mono backend is available and used, everything behaves as expected, but switching to IL2CPP causes the below error messages, regardless of whether the navmesh agent is pre-existing or instantiated at runtime. I have already tried many potential solutions including Warp() or setting position before enabling the agent, rebuilding NavMeshSurfaces at runtime before instantiating the agents, and have switched back to the legacy NavMesh system to rely on baked navmesh data, none of which have changed anything. We have tested with extremely basic Navmesh agent wander behaviour and it seems clear that the backend is somehow affecting the references to Navmesh or the mesh data itself. Has anybody experienced this problem, or do you have any ideas for workarounds/solutions? I hope someone can help, thanks!
