The huge problem with using SteamVR, or Oculus, or any of these solutions, is for monetary reasons, they push the cloud so hard, it breaks important use cases.
Like having a ‘headless ghost’ 4k Monitor attached, only to hear the ‘ding ding’ of SteamVR warning that launching an app could cause sync problems, bla bla, manual intervention on desktop required.
This is why we need Virtual Desktop 100% standalone, integrated with PiTool, just like PVRHome is.
EDIT: Just to be clear, use of the phrase ‘old man’ in this meme is completely coincidental to the content of this post, with no stereotyping or otherwise whatsoever intended.
Another outage, another failure. After a while of apparently not needing to connect to Steam servers before launching SteamVR, now, it breaks again, failing to launch Virtual Desktop from PVRHome hook.
Unless someone gives a reasoned argument to stop, I am just going to keep posting to this topic every time SteamVR fails to get me back to Virtual Desktop.
Yet another problem with SteamVR today. Will not start without a full reboot of the MSW OS. Actually, this has been happening for a while now, but I can finally confirm there is NO WAY to cure it short of full reboot. Not uninstalling disconnected devices USBDeview, not stopping/restarting things in “services.msc”, not closing programs like Voice Attack or Precision X1, and not closing Steam/SteamVR/PiTool/etc processes in Task Manager.
Restarting the PC breaks the state of some Virtual Machines applications (eg. Okular) in use with shared folders.
PiTool PVRHome, IIRC, does work without a full reboot, demonstrating this is a problem with SteamVR, or the way SteamVR must be managed by PiTool.
And another problem today. This time SteamVR has moved the files used for things like ‘Room Setup’ and video resolution, breaking my scripts, making it even less likely VR applications will just work. Since this is the beta, it is an indicator of things to come…
EDIT: Applies to non-beta too!
EDIT: To allow Virtual Desktop to be used as a PVRHome replacement in offline mode (stopping SteamVR updates), a script has been added to my hooks to disable the interactive ‘warning’ message at every launch.
EDIT: Scripts updated to work with the new files location as well as the old. Nonetheless, my point about the lack of a stable interface stands.
This time, SteamVR, somehow, seems to have ignored its vrsettings file, despite not having made any changes recently, setting the resolution way too high for DCS World. After reconfiguring, and verifying this is not going to become a common occurrence in some way, restarting SteamVR results in the headset disconnecting from it - despite working normally with PiTool as usual. To address these issues in the future, a 7 second skippable delay was added to the terminate batch script (among other changes), so the user can answer any interactive “are you sure you want to shut down” prompts SteamVR may issue before graceful shutdown.
My lack of posts to this topic is not for lack of SteamVR failures! Oh no, just that I have been too busy solving them to document!
Launching overlays OVRDrop and WorkInVR is again failing intermittently, regardless of underling VR app or VRAM usage. Since this was working at least more reliably before, and is less reliable now, PiTool or refresh rate semantics is not the (only) problem.
Moving my portable monitor from USBC port to an HDMI port reordered the display numbering, fouling up OVRDrop panel presets. This required a regedit hack (now part of the increasing set of OS/MSW workarounds included with extendedInterface) to renumber.
Dangerously, both RWin and LWin + “P” can change the current monitor layout, which cascades to USB failures, which can interact with at least JoystickGremlin/VJoy to spill out anomalous commands/typing. Arguably, this might be considered an MSW flaw, but I am faulting SteamVR because it could have easily occupied this global keybinding, just as a simple autohotkey script compiled to an exe can do.
Now OBS will not record from OpenVR Capture at anything near full framerate. This is almost certainly because SteamVR updates changed something. At the worst possible time.
EDIT: Confirmed! SteamVR Mirror FPS is drastically reduced now!
Why are y’all using the BETA SteamVR version? I’ve been using the non-beta SteamVR and have not had such frequent problems (but even that version has not been trouble-free).
Because I actually haven’t been? I only briefly switch to Beta when stable fails, and then it usually turns out Beta also fails.
Meanwhile, I put this in my hook batch script to only start SteamVR after network connection is available. I wish to stress this in no way affects my previous reports on this thread of SteamVR outages, which each reflect multiple successive failed connection attempts.
SteamVR, or presumably any management/development forces behind it, are becoming such a problem, I am tempted to, but not yet making, a video, point-by-point, basically, this, to one day go down as a real-life example.
Which I would only ever consider doing because it would still be more focused on how they could stop causing these problems, and actually enjoy a better business in the process.
Feel free to let me know if there is any interest.
Ah, FORGET IT. Locked or not, it’s not like SteamVR corrected any of the outstanding bugs - most notably OpenVR mirror performance. So I am bumping this old thread, again.
Today, SteamVR tells me it needs to be reinstalled, corrupt, bla bla, ARGH! As it turned out, just needed an update. Minor issue, but one of several to happen as recently as the past few as well as over the past few months, each time leaving me to dread how many weeks of work time I might lose this time.
By now I have also ascertained with certainty what I have long suspected - the compositor architecture for SteamVR is as arcane and stupid as it could get. Give overlay programs the tracking information, controller information, and a couple of framebuffers to write to. The workarounds developers have to go through to send SteamVR the expected 2D textures in 3D space take a ridiculous amount of time for them to figure out.
See all those desktop overlays like OVRDrop and XSOverlay? SteamVR imposed an extreme tax, measurable in weeks (more like years actually) of brain cycles, each.
Scrap SteamVR! The developer community is small and does not have time for such stupidity. EVEN THE USERS DON’T HAVE TIME FOR THIS!
