[Feedback] Being able to connect to a remote SlimeVR

[Lusiiky]

Hello,

I assume that your Feeder App only connects to a local SlimeVR, and I'd like to know if it's possible for you to offer at least one place where we can indicate an IP address where SlimeVR would be (while using Tailscale for example, for Shadow users).

It would be MUCH more convenient for us, cloud users, to actually have remote access to SlimeVR.

Thank you very much, Lusiiky

[Erimelowo]

You can use VRChat OSC Trackers in the SlimeVR Server

[Lusiiky]

Um... yes, but I'm talking about managing SlimeVR and being able to use the Feeder's functions (reset, etc.)..

[kitlith]

So. The feeder currently uses named pipes instead of any internet protocol, so it's not that simple. (Granted, I think there's something about named pipes over network shares but.) There was interest in switching it over to using websockets at some point, but that hasn't happened yet.

Moreover, even if the feeder app did use websockets, it still needs to run on the same machine as SteamVR (since it's an openvr application), which is presumably the same machine as the slimevr server since the slimevr openvr driver also uses named pipes.

Unless the point is to run a local SteamVR instance and a remote SteamVR instance and relay physical inputs from the local instance to the remote instance of SlimeVR?

But either controller inputs are making their way over to the remote machine (meaning you can play vr games, and feeder app would function fine on the remote machine) or they aren't, which would mean you need a more comprehensive solution that is out of scope here.

@Lusiiky is there something I'm missing here, or does this explanation help?

[Lusiiky]

Hello!

In fact, here is my configuration:

SlimeVR > SlimeVR Server (IP of Tailscale like 10.x.x.x) > Tailscale VPN to Shadow > VRChat with OSC datas of SlimeVR Server

The problem is that I have to remove my headset and go to the computer where SlimeVR and Tailscale are physically present in order to reset the position in SlimeVR Server.

So I thought it might be possible for your application to simply and easily transfer data via an IP: since Tailscale gives an IP to my local PC and my Shadow, I thought it might be possible to tell your application that instead of contacting the SlimeVR Server on the local PC where SteamVR is, it should contact a SlimeVR Server at a specific IP. But I don't really know how your application works, so...

Thanks a lot!

[kitlith]

Okay, if I understand correctly @Lusiiky: You're running SlimeVR Server locally, and steamvr+vrchat remotely on the shadow PC, and using OSC with VRChat to make that work.

I do have a little interest in making feeder app work with similar setups, but it would take some time, and some enthusiasm I don't have right now.

What I would probably do (and what the slimevr documentation recommends) is running slimevr server on the shadow PC as well. This would avoid the need for OSC, and should reduce latency by reducing the number of networking roundtrips. However, I'm told that the approach taken in the documentation doesn't work anymore (and i'm a little horrified at the proposed solution to begin with)

There are two approaches we could take here:

• Setup a little proxy to forward from the local computer to the remote computer (kinda like port forwarding on a router)
  • I don't know of a simple tool with a UI that does this, but I wouldn't be surprised if one exists.
  • one CLI tool that exists is "Simple UDP Proxy/Pipe" from this page: http://aluigi.altervista.org/mytoolz.htm
    • The command for this is sudppipe.exe 10.x.x.x 6969 6969 (you could probably put this in a batch file next to the executable)
  • Any other UDP proxy would work here, too, as long as it can tunnel responses back as well.
• Find another way to hook the shadow PC up to your local network.
  • Tailscale, since you're already using it, has the concept of a subnet router, which can allow devices on the tailnet to interact with your local network and visa versa.
    • I don't know if this forwards broadcast packets, which are what the trackers use to try and find slimevr server.
  • This is really overkill

While I don't have a Shadow PC to try and test things, I was able to point slimevr wrangler (aka the thing that handles joycons) at a machine running sudppipe which was pointed at the machine running slimevr server.

Let me know how things go! Feel free to poke me in the slimevr discord if you have issues. My name on discord is the same as on github.

[Lusiiky]

@kitlith Hi there! Thank you for your reply.

The problem is that SlimeVR doesn't work in my configuration without OSC. I've tried to do pretty much as the documentation explains, just with a few updates, except that I have incredible latency and what little latency or peak latency I have accumulates, and so after just two minutes of play I have several seconds of accumulated latency, and obviously SlimeVR Server hasn't thought to limit the latency between the trackers and the software in order to reduce latency as much as possible even if it means, unfortunately, losing data for example. (Setup: with tailscale, I redirect a USB > Ethernet adapter in order to physically connect my Shadow to my local network).

I've also tried connecting my trackers to my router, which has a port redirector that redirects SlimeVR ports to my PC, which has Tailscale, and will therefore be redirected to Shadow and effectively run SlimeVR Server without a direct connection to the local network. Unfortunately, as it's the local PC that's sending the data, SlimeVR Server can't separate the trackers (as they all have the same IP), so it can't work.

I think your two methods can be combined with what I've already tested here (maybe not your first proxy idea... I'll have to look).

The only method that works today is to use OSC. And as SlimeVR doesn't seem to be very responsive to my more complex than normal setups, I unfortunately have no way of working otherwise and having SlimeVR Server running on my Shadow.

Thanks!

[kitlith]

@Lusiiky the proxy program I mentioned uses a different source port per source address, and slimevr server sends data back to the the port that it was recieved from, so it should work exactly the same way that it did with my local test between two computers, but without shadow PC.

Router port forwarding shouldn't be required in any of these scenarios, as the trackers are inside the network sending broadcast packets, not outside the network pointing at your public IP address.

[kitlith]

Here's an update on stuff:

• The documentation was updated to use VirtualHere for USB forwarding instead of the USB forwarding built into Shadow PC, since the latter doesn't work anymore.
• I drafted a PR a few weeks ago that changes how SlimeVR Server tracks connections to hopefully make software forwarding/proxying more viable. https://github.com/SlimeVR/SlimeVR-Server/pull/753
  • It's still in need of serious testing (aka I don't know if it works at all) but if you want to mess with it, here's a build from CI: https://github.com/SlimeVR/SlimeVR-Server/suites/14012147501/artifacts/782063049

[Fummowo]

Wouldn't a small application like a SlimeVR Forwarder work perfectly in this scenario? Similarly to how SlimeVR Wrangler sends data to the SlimeVR Server, the Forwarder could connect to your slime trackers like the Server and them forward them on to the actual server over the network :)

[kitlith]

yes, that's another, orthogonal way to do it. That's creating new, purpose-built software, whereas I'm trying to first ensure that a bug in the server is fixed and enable intuitive use of off-the-shelf software.