On Linux, Quven is a server. The Server-only AppImage is built for an always-on host that can keep or mount the library and serves the native and web clients on your other devices. The host itself never draws a frame. That’s the client’s job.
A server-first Linux shape
You can run the AppImage interactively to set things up, or install the service lifecycle and leave the host alone, and whichever you pick the server will expose its management and media APIs to the clients you’ve authorised while the watching happens on Windows, on macOS, in the hosted web client, or in the mobile apps as they clear their store gates.
Architecture and media tooling
Which build do you need? x64 for an ordinary PC or server, ARM64 for a Raspberry Pi and its relatives. Each one carries its own matching .NET payload and the FFmpeg tools, so there’s nothing to install first.
The x64 path has native Ubuntu runtime evidence behind it. ARM64 goes further: a Raspberry Pi 4 has been through startup, headless CLI and V4L2 M2M hardware transcoding on real hardware, on top of the static architecture and public-feed checks both builds get. But one board is one board. You should treat other ARM devices and NAS models as untested until somebody’s actually tested them, whatever chip the box carries and however close its spec sheet looks to the Pi’s.
Plan around permissions and acceleration
The service account needs read access to every mounted library path and execute access to the bundled media tools. GPU acceleration will depend on host drivers and device permissions on top of that, even if the same card worked fine under another distribution.
A process that starts proves very little. It can’t prove playback. Play one real transcode and one direct-play session before you call the installation done.
For an unattended host, you should write down the AppImage path, the service unit, the data directory, and whatever the library mounts depend on. Then test a cold boot. No interactive shell, and health and logs inspected from another machine. And getting a browser to connect doesn’t prove as much as it seems to. Restart the host while it’s idle, watch the service come back, and replay the same direct and transcoded samples with your hands off the permissions.
Server-only, on purpose. The Linux download in v1 ships the server alone. A Linux desktop client is planned for later, so expect the package to give you a host, not a ten-foot UI.
Frequently asked questions
Is there a Linux desktop client?
Not in v1. The download is deliberately server-only, and the desktop client’ll come later. What you get is a host to point your other devices at, and the watching happens on them.
Does it run on a Raspberry Pi?
A Pi 4 has real-device evidence behind it: startup, headless CLI and V4L2 M2M hardware transcoding. Whether your particular ARM board or NAS will behave the same way is an open question, and one board proven is exactly that.
Do I need to install FFmpeg or .NET first?
No. Both builds arrive with .NET and the FFmpeg tools already inside, matched to the architecture. What the service account will need is execute access to those bundled tools and read access to every path your library is mounted from.