Everything in this post is optional. If SysDVR works for you, you need none of it — close the tab and go play. What follows collects the switches and files the author documents for edge cases: a mini-PC that can’t decode in software, a two-console household, a manual install with no GUI, a console you’d rather keep quiet on the network. One boundary before we start: no flag here changes the 720p30 feed. These are plumbing tweaks, not quality unlocks.
Cheat sheet
| Flag / file | What it does | Reach for it when |
|---|---|---|
| –legacy | Runs the client as a simple video window, no GUI | You dislike the GUI, or your manual install lacks the GUI library |
| /config/sysdvr/no_adv | Stops the console broadcasting for discovery | You always connect by IP, or want a quiet console |
| –decoder <name> | Picks a specific ffmpeg decoder for the player | Software decoding is too slow on a weak PC |
| –hw-acc | Auto-picks the first hardware decoder it finds | Same problem, quick first attempt (see the warning) |
| –serial <serial> | Targets one specific console over USB | Two consoles are plugged in / discoverable |
| –debug dynlib | Verbose dynamic-library loading output | A manual dotnet install fails with library errors |
1. –legacy — the simple player window
Launch the client with --legacy and the modern GUI disappears, leaving a plain window with just the video and no buttons — the pre-6.0 style player. Some people simply prefer it. It’s also functional, not just cosmetic: on manual dotnet installs, --legacy lets you run the client without the CimguiSDL2Cross GUI library the full interface needs, per the official client setup guide.
2. Turn off discovery with the no_adv file
TCP Bridge discovery works because the console continuously broadcasts UDP packets announcing itself. To stop that, create an empty file named no_adv in /config/sysdvr/ on the SD card (create the folders if they don’t exist; on Windows, make sure the file has no extension). Consequences to accept before you do it: the client can no longer find the console automatically, so you connect by typing the console’s IP address manually — softened by the fact that since v6.3 the client remembers the last manual IP you used.
3. Hardware decoding — –decoder and –hw-acc
The client’s player decodes the H.264 stream with ffmpeg, and by default that means a software decoder. On a strong PC that’s invisible; on a mini-PC or old laptop it can be the whole bottleneck. The documented way out:
- List the decoders in your ffmpeg build:
dotnet SysDVR-Client.dll --show-decoders. The entry namedh264is the default software one; the part before the colon is the name you can pass. - Launch with
--decoder <name>to use a hardware decoder your machine actually has. - Or try
--hw-acc, which picks the first decoder it can find automatically.
The author’s warning on –hw-acc: ffmpeg lists every decoder enabled in the build, including ones for other vendors’ hardware — an Intel decoder can appear on an AMD machine, where it will not work. If –hw-acc misbehaves, that’s why; list the decoders and pick yours explicitly with –decoder.
4. Screen-off streaming
Since SysDVR 6.1, the console’s screen can be off while it streams. It’s a small feature with an outsized effect on portable setups: pair it with the phone-as-monitor setup and the Switch rides dark in your bag, sipping battery, while the phone does all the displaying. It’s also the polite option for late-night RTSP viewing on a TV across the room.
5. Multiple consoles — –serial and manual IPs
Two hacked Switches in one house confuse auto-everything. Two anchors fix it: over USB, target one console explicitly with SysDVR-Client.exe usb --serial <serial>; over the network, skip discovery and connect to each console by its own IP address (the client remembering your last manual IP makes the second console the only extra typing).
6. The connection hierarchy, from the author’s own list
The official tips page ranks streaming setups from best to worst, and it’s worth internalising because no flag beats physics: (1) console and PC directly linked by LAN — best, but genuinely advanced, since you must host the DHCP and connection-test services yourself; (2) console and PC both wired to the same router; (3) console near a 5 GHz router with the PC wired. If you’re below rung 2 and fighting stutter, moving up a rung will do more than every flag in this post combined — the lag fix guide works through it.
7. –debug dynlib — for broken manual installs
If you installed the cross-platform dotnet build by hand (Raspberry Pi, Windows on ARM) and the client dies with library-loading errors, relaunch with --debug dynlib: it prints detailed dynamic-library loading information so you can see which native library is missing or mismatched. Niche, but when you need it, nothing else substitutes.
A note on versions
Flags are documented against the current client, and the tooling moves: --file disappeared in the 6.0 rewrite and returned in 6.3; the GUI itself — and with it the need for --legacy — only exists since 6.0. If a flag here is rejected, run SysDVR-Client --help on your build to see what it actually accepts, and treat a mismatch as a nudge to update both sides rather than a dead end.
Next steps
- TCP Bridge mode — the mode most of these tweaks orbit.
- SysDVR Settings app explained — the friendly, on-console switches.
- Stay current — tweaks land per release, and every build is on the download page.