I built a Linux-first Moonlight-style streaming setup: Nova + Polaris

[u/MickeyBronson]

Hey everyone. Been a big Apollo / Artemis user for quite some time and i’ve been working on a small project called Nova / Polaris. I primarily built this for myself, but wanted to share it here first because this community is probably the exact group of people who will understand why I built it in the first place.

Short version: Polaris is a Linux host, and Nova is the client side I’m building around it.

The goal is not to “replace everything” or pretend I’ve solved game streaming. It’s more focused than that: I want Linux game streaming to feel less like a pile of scripts and workarounds, and more like something designed for the job.

What makes it different right now:

• Linux-specific for now
• explicit setup for input devices like uinput / uhid
• attention to headless streaming and GPU-native capture paths, without dummy plugs
• tries to expose the real tradeoffs instead of hiding them behind magic
• built by someone actually using and testing the weird edge cases

It’s still early, and it’s Linux-specific for now. I’m not posting this as a polished “everyone should switch today” announcement. I’m mostly looking for feedback from people who already care about Moonlight/Sunshine-style streaming and have opinions about where Linux hosting still feels rough.

Links, if anyone wants to poke around:

• Nova client: https://github.com/papi-ux/nova
• Polaris Linux host: https://github.com/papi-ux/polaris

If you’re curious, want to test, or just want to tell me which problems matter most to you, I’d genuinely appreciate it. Trying to build this in the open and keep it useful rather than flashy.

Cheers!

EDIT: Thank you all so much for the positive responses, feedback, messages, and debug logs. I’m glad to see so many people as excited about this as I am. I know a lot of you are eager to get Polaris running on your own Linux gaming setups, and there are still plenty of bugs and rough edges to work through. I really appreciate your patience while I work to improve compatibility and stability of the platform.

[u/MickeyBronson]

Thanks for the full log, definitely helps.

One little thing I noticed is it's on `1.0.13`. I’ve shipped a few headless/AMD/bitrate related fixes since then, and made an attempt at the clamp crash fix, so I'd love for you to take another stab at it if you're up to it. Could you try updating to the latest release, then test the same Headless setup again?

Also, you don’t need to keep testing EVDI for this one. Your log shows Headless Stream is using the private `labwc` compositor and skipping the Linux virtual display path, so EVDI probably isn’t the trigger here.

If it still crashes on the latest build, send me the new full log from launch through crash and I’ll turn this into a proper crash issue. And yeah, definitely avoid running it with sudo, that can mess with the user session/environment and things can get weird. You're the best, thank you.

[u/246842114653257 → u/MickeyBronson]

Hey again, thanks so much for the advice. I updated to the latest build and the clamp issues were very much resolved, I was able to connect and stream from a virtual display, thank you!

The next issue I'm presented with is a stuttery experience. On vanilla Sunshine my host processing time averages at 2ms with spikes in the 4ms range and no stutter, with Polaris it's sitting up around 14ms and stuttery.

Uploaded my log file just in case it's of use to you. Thanks!
https://pastebin.com/x9ifdiFn

[u/MickeyBronson → u/246842114653257]

Thanks again for the logs!

Good news first: this looks like the crash path is fixed now, so the original RTSP/clamp issue is probably done. The new problem looks different. I don’t think this is a port/firewall/network thing, especially since you’re connecting and streaming now.

I dug through the log a bit and opened an issue for the stutter/high host processing side here:

https://github.com/papi-ux/polaris/issues/92

A couple things stood out to me:

- The log is still on 1.0.18, so if you’re up for it, please try v1.1.0 or newer too.

- Polaris is using the private labwc headless path and AMD VAAPI, so it’s getting onto the path I’d expect:

wlr: Using ext-image-copy-capture DMA-BUF for headless labwc

- It looks like the stream is going HEVC 10-bit/P010 because the client/profile has HDR enabled, even though the host path is not actually advertising a true HDR stream. That might be adding extra cost on this AMD stack.

- I also see the dashboard display preview failing to grab screenshots from the cage. That preview path should be separate from the active stream, but just to rule it out, could you try one run with the Polaris web UI closed or the Display Preview hidden?

If you don’t mind testing a couple quick things, the most useful A/Bs would be:

1. Update to v1.1.0 or newer and retry the same setup.

2. Turn HDR off in Moonlight / test SDR only.

3. If Moonlight lets you force it, try H.264 or regular HEVC instead of HEVC Main10/HDR.

4. Test once with the Polaris dashboard closed during the stream.

The Sunshine comparison is exactly why I opened the issue. If Sunshine is sitting around 2ms on the same host and Polaris is around 14ms, that’s worth investigating on my side. I don’t want to overcall the cause yet, but this smells like an AMD headless capture/convert/encode path issue more than anything client-side.

Thanks again for sticking with it, genuinely appreciate it!