USB, DP, Power are all connected. 8k+ won’t get detected until I reboot my PC. Then when I turn it off I can’t get it connected on another turning on.
I get error 10500.
My 5kXR doesn’t have this problem and can be connected/restarted multiple times without issues.
I tried earlier Pitool versions. I tried test firmware Pimax support provided over email a few times and it seemed as the issue is fixed for some time, but no, didn’t happen. Currently I am at latest FW Pitool provided - 2.1.255.264.
Edit1: Restarting service or headset obviously doesn’t work.
In newer PiTool versions there is a button to restart the Pimax service. This usually helps.
Would be good if this weren’t necessary, there is still some work to do.
Ok, never mind. It helps for me. Perhaps you can unplug other USB devices (or even deactivate their drivers) to find out which one might be interfering?
There has to be something that is different when you restart your PC compared to when you just restart the HMD and service. E.g. the order in which drivers are loaded - so it might be that it just connects when a certain other interfering driver isn’t loaded yet.
You might enable boot logging (explained e.g. here: How to enable 'Boot Log' on Windows 10 | Windows Central) and check what is usually loaded after the Pimax service.
I guess you are using the same USB port when connecting the 5k xr or the 8k+, so different usb controllers (that might be shared with different sets of other usb devices) can be ruled out?
I tried restarting pimax while headset is turned on. I tried disconnecting usb, power and dp, restarted services, restarted headset - all failed. Any specific steps and order I should try?
What GPU and driver version are you using? I had this problem a while back, for a number of nVidia driver versions (covering a period of a few months). The last few driver versions are OK. I’m using currently using 251.48.
aorus 2080 xtreme
445.87 driver released at 04/15/2020
I’ll update it today, but I really don’t think it’s an issue, since I did an update before and had to roll back my system after it started glitching my mouse cursor out.
Ok, apparently no special kernel space drivers are involved then, the service (called “PiServiceLauncher”) seems to only use default usb drivers. The way how the load order of services is determined is more complicated, it is determined by some registry keys.
One thing you could do to check whether it’s even worth to continue looking at the load order of the services:
keep the HMD disabled
boot the PC and wait until all services are loaded
manually unload and reload the Pimax service (either via PiTool or via the Services menu in the task manager). Now the service should be loaded as the last thing in the load order (until reboot).
Now switch on the 8k+ and see whether you get a connection
If you get no connection then investigating further which services might interfere could potentially help (e.g. by disabling everything that isn’t strictly needed and seeing which service that is loaded after PiServiceLauncher is problematic)
If it still works the first time even with the service loaded as the last item, then playing with load order wouldn’t help anyways.
In both cases it would be helpful to open a ticket to get a 2nd level Pimax technician looking at the logs with you. (I did this with my first 5k+ when it lost connection after a few seconds, they tried a few things until they were convinced that the hardware is damaged). If you can already tell which service interferes this might help, if not they would at least already know that load order isn’t the issue. (If load order is the issue this would explain why reloading the service doesn’t let you work around the problem that way to start the HMD a second time per boot. But there would still be something wrong that is in an invalid state after the first shutdown of the HMD.)
P.S.: One thing you might still try: Disabling and reenabling the USB controller, e.g. in case it is left in an invalid state after the disconnect: It is method 3 described here: USB port may stop working after you remove or insert a USB device - Microsoft Support
They mention a workaround where the selective suspend feature is supposed to be disabled - might be worth a try.
I did as you told - restarted pimax service in app after rebooting while headset is not connected (piservice is still not in the logs), then connected headset, played a bit, and turned it off. I managed to turn it back on after first turnoff, and it kinda connected but reported as not tracking for more than a minute in direct line of sight of base station. I restarted service again, and it again reported as not tracking for some time, and caught tracking right befoore I clicked reboot hmd, after what I’m getting 10500 error again.
Selective USB suspend is disabled by oculus tray tool. I just verified it’s not the case.
Ok, then the order in which the services are started doesn’t seem to have been t the problem.
The behavior is really odd - completely stable on first connect and unreliable at subsequent connects (then the USB controller state stuff can also be ruled out - there it wouldn’t reconnect at all after it didn’t reconnect once until the next restart).
Still sounds unhealthy, sorry, am also out of ideas at this point. Would open a ticket.
P.S.: For my first 5k+ the behavior was as follows: It always connected the first time but automatically disconnected after a few minutes. Then I could connect it again after some cooldown. The longer the cooler it got. Was apparently a problem with some parts overheating.
But for you it seems to run indefinitely once it got a connection the first time. That speaks against such an overheating problem.
I toyed with services - disabled Pimax service startup (now can only be started manually by restarting it in pitool). I also uninstalled some apps (motherboard bloatware, avermedia drivers, expressvpn).
I opened task manager, sorted by PID and killed a few tasks which loaded last (such as Acronis daemon) and managed to have 5 successful HMD restarts. Reebooted next.
After reboot I decided not to kill anything and managed to get 3 successful restarts after which it ended at 10500 again. Killing processes didn’t help. Idk, it’s random af… But at least I confirmed it can handle more than 1 restart. Will keep experimenting.
I had many issues with acronis scheduler. Did need to disable the scheduler service to cure the pc not responding for many seconds. I used an older acronis version (of 2014 or 2017, can’t remember) so probably fixed with newer versions.
If i need to backup/mount an acronis image i now install it and after things done i deinstall it immediately. My personal fix because i do not use it very often anyway…
Well, it’s not Acronis this time. Without killing anything I had 2 successful restarts now. Restarted service - once as it wouldn’t see base stations after those restarts. Then pressed “reboot hmd” - again it saw base station just before HMD restarted, and ended up at 10500 once more. Maybe important that system produced usb disconnection sound at reboot which was final, and then - after some time produced usb connection sound. This made me wonder what USBlogView will tell us.
I restarted the system once again, waited for all apps to load, then started usb log view and pitool. Restarted service to enable it.
Interesting. Now it’s stuck at 10500 after usb disconnect sound.
After some time - usb connect sound. Several more devices are added with long intervals without any sound. 5-th device on port 0003 produced another connection sound and looks like it stopped after that:
The guys who wrote the Pimax service might probably be the people to get into the loop. Best open a ticket. First level support might most likely not be able to help, 2nd level probably also not, but as this problem looks like something that could improve connection stability overall for all customers and as it is so nicely reproducible, they might decide to assign their device driver guys to the case.
I’ve created a ticket. I wonder what we’ll get out of it. I’ve updated pitool to 261 version, but it didn’t fix the connection issue for me despite it being advertised in changelogs.
