Cheat sheet

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:

1. List the decoders in your ffmpeg build: dotnet SysDVR-Client.dll --show-decoders. The entry named h264 is the default software one; the part before the colon is the name you can pass.
2. Launch with --decoder <name> to use a hardware decoder your machine actually has.
3. Or try --hw-acc, which picks the first decoder it can find automatically.

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.

What you need

• A hacked Switch running Atmosphère with SysDVR installed — start with the install guide if needed.
• For the client app: a phone running Android 10 or later on a 64-bit device (32-bit support was added in SysDVR v6.2, which widens the net a little).
• Console and phone on the same Wi-Fi network for the wireless routes, or a USB cable for the wired route.
• A streaming-compatible game — long-press the capture button in it; if a clip records, it will stream.

Route A — The SysDVR-Client app (recommended)

1. Install the official SysDVR-Client APK on your phone (safe procedure in the APK guide).
2. On the console, open SysDVR Settings and set the streaming mode to TCP Bridge — the low-latency network mode with automatic discovery.
3. Launch your game on the console.
4. Open the SysDVR-Client app on the phone, on the same Wi-Fi. Your console should appear via auto-discovery — tap it (or enter the console’s IP manually if it doesn’t).
5. Prop the phone up, pick up your controller — Joy-Con or Pro Controller, paired to the Switch as always — and play. Game audio plays through the phone.

Route B — An RTSP player (nothing to install from GitHub)

If you’d rather not install the client, any RTSP-capable player turns the phone into a viewer:

1. On the console, set the streaming mode to Simple Network in SysDVR Settings.
2. Open mpv for Android or VLC on the phone and open the network stream rtsp://<console IP>:6666/.
3. Launch the game and watch it on the phone.

Expect more buffering and latency on this route — RTSP players cache for smoothness, which is the opposite of what live play wants. It’s fine for turn-based games, RPGs and spectating; for action games, use the client app. The RTSP mode guide covers latency settings on the player side.

Route C — USB to the phone (lowest latency)

The Android client can also receive over USB, and Android receivers need no driver setup at all. A cable makes this the lowest-latency portable setup — the phone becomes a true wired monitor. One known weak point, straight from the official guide: USB-C-to-C cables can be unreliable for SysDVR’s USB mode, so if the connection drops or never appears, try a different, shorter, good-quality cable before troubleshooting anything else.

Latency and battery honesty

• Wi-Fi quality decides smoothness. Same strong network for both devices, close to the router or hotspot. Your internet speed is irrelevant; the stream is local.
• The feed is 720p30. On a phone-sized screen that looks sharp — this is the one display where SysDVR’s hardware cap barely matters.
• Turn the console screen off. Since SysDVR 6.1 the console’s screen can stay off while it streams. Use it: the Switch doesn’t need to glow inside your bag, and you’ll save real battery. (More switches like this live in the advanced tips.)
• A small phone stand changes everything. Propping the phone at eye level, controller in hand, is the difference between a gimmick and a setup you’ll actually use on a train.

Rather go bigger — or smaller?

The same app-and-player logic scales up to the TV with an Android TV box (with real caveats about cheap hardware — see SysDVR on Android TV) and sideways to a laptop screen with the laptop-as-monitor setup. The phone remains the sweet spot for travel: it’s the screen you already carry.

Troubleshooting the phone setup

• The console doesn’t appear in the app: confirm both devices are on the same network, then check the router for AP/client isolation — many routers, and nearly all public hotspots, block devices from seeing each other, which silently kills auto-discovery. If discovery stays blocked, connect by entering the console’s IP address manually.
• The app won’t install: check the phone against the real limits — the client needs Android 10+ on a 64-bit device (32-bit support arrived in v6.2). The official guide is blunt that older devices, smart TVs and similar hardware may simply not install it; that’s a platform limit, not a broken APK. Re-download from the official GitHub release before concluding anything.
• The picture freezes on venue or hotel Wi-Fi: that’s AP isolation plus congestion, the worst combination for local streaming. Your own travel router or a phone-hosted network you control will beat it every time — the stream is local, so it never needed the venue’s internet in the first place.
• USB connection drops: swap the cable before touching settings. Cable quality is the documented weak point of USB mode.

Next steps

• Install the Android client safely — GitHub-only, hash-checked.
• TCP Bridge mode — the mode Route A is built on.
• Lag and desync fixes — if the picture stutters on hotel Wi-Fi.

The two ways to get the picture into OBS

The official SysDVR tips page makes the same recommendation from the other side: the client modes exist precisely to avoid RTSP’s buffering. For a main gameplay source, capture the client window. The RTSP mode guide explains the feed itself if you use the media source route.

Setup, step by step

1. Get SysDVR running: install the sysmodule (see the install guide), set your mode — TCP Bridge for a network setup, USB if the console sits by the PC — and connect SysDVR-Client until you see the game. Client downloads are on the download page.
2. Add the source in OBS: for the window route, add a Window Capture and select the SysDVR-Client window. For the media route, add a Media Source, untick Local File, and enter rtsp://<console IP>:6666/.
3. Wire up the game audio: your stream must hear the client. Use OBS’s application audio capture aimed at SysDVR-Client, or route the desktop audio the client plays through — then play something with sound and watch the OBS audio meter move before you go live. Silent gameplay VODs are almost always this step, skipped.
4. Set the output to match the source: a 720p30 stream (or recording) is a 1:1 copy of what the console sends. A 1080p canvas only upscales the same pixels and costs you encoder headroom — spend that headroom on bitrate and a clean picture instead.
5. Connect the platform: add your Twitch or YouTube stream key in OBS settings as usual, run a two-minute test recording, and check picture, audio and sync in the file before your first real stream.

Scene basics worth the five minutes

• Gameplay scene: the SysDVR source fullscreen. Keep the client window open behind OBS — minimizing it can pause a window capture on some systems, so park it on a second screen or behind OBS instead.
• Facecam scene: the same gameplay source with your camera in a corner. Nothing about SysDVR changes; it’s just an OBS layout.
• Starting / break screens: a static scene to switch to. Bonus: switching scenes is also how you hide the black screen SysDVR shows on the Home menu, which is never streamed — launch games behind your break screen and cut back when the picture’s live.

Sync and stability over a long stream

If game audio slowly drifts away from the picture during a long session, the lever is on the SysDVR side: the client’s Disable A/V sync option trades a bit of sync precision for lower latency and often settles drift. The full diagnosis path — connection hierarchy, cache flags, when to switch modes — is in our lag, stutter and audio desync fixes. The short version of connection quality: wired LAN beats a shared router, which beats a nearby 5 GHz Wi-Fi signal; your internet speed is not the variable, because the console-to-PC hop is local.

Recording while you stream costs nothing extra to set up — the same OBS sources feed the recorder, as covered in record clips and screenshots with SysDVR.

When to graduate to a capture card

SysDVR is the right tool while 720p30, a CFW console and recording-compatible games cover what you stream — which is most indie, retro, RPG and casual content. A capture card earns its money when you need 1080p60, docked play on a TV at the same time, or a completely stock console. Our SysDVR vs capture card comparison and the best capture cards for Switch roundup mark the exact line, so you can upgrade when — and only when — it actually buys you something.

Pre-flight checklist

Run this two minutes before you go live; it catches every boring failure while it’s still private:

• Versions matched? Console sysmodule and client on the same release — the mismatch is silent until it isn’t. (Update guide, if not.)
• Picture live in the client with the actual game you’ll stream running — not the Home menu, which never streams.
• Audio meter moving in OBS with game sound playing, and a test recording played back with your own ears.
• Client window parked, not minimized — on a second screen or behind OBS, so the window capture can’t pause.
• Break screen ready to cover menu navigation and any mid-stream troubleshooting.
• Test recording from this session — not last week’s — checked for sync. If audio has drifted, you want to meet the A/V sync fix now, not live.

Next steps

• Stream to Discord without a capture card — the lighter-weight version of this setup.
• Play Switch on a laptop — the same feed, used as your own screen.
• Advanced SysDVR tips — decoder and discovery tweaks for streaming PCs.

Before you start

• SysDVR installed on the console — the install guide takes about five minutes if you haven’t done it.
• The client receiving the stream on the same PC you’ll share from. TCP Bridge is the tidy choice for a desk setup; USB gives the lowest latency if the console is next to you. Client files are on the download page.
• A game that streams: long-press the capture button in it — if the console records a clip, you’re good.
• The Discord desktop app. Window and audio sharing are far more limited in the browser version.

Route A — Go Live on the client window (simplest)

1. Start the game on the console and open the stream in SysDVR-Client. Fullscreen the client window for a clean picture.
2. In Discord, join a voice channel in your server (or a DM call).
3. Click Screen (Go Live), open the Applications tab, and pick the SysDVR-Client window.
4. Click Go Live. Your friends click your name to watch.

Audio takes care of itself on this route: sharing an application window in the Discord desktop app carries that application’s audio along with its picture, so the game’s sound — which the client is already playing on your PC — reaches your friends. This is the main reason to prefer Route A for casual sessions: one share, picture and sound together.

Route B — OBS Virtual Camera (for a produced picture)

1. In OBS, build a scene with the stream in it: a Window Capture of SysDVR-Client, or a Media Source pointed at the console’s RTSP feed. Add your webcam, overlays and alerts as you like.
2. Click Start Virtual Camera in OBS.
3. In Discord, join a voice channel, turn on your camera, and select OBS Virtual Camera as the video device.

Keeping the shared picture smooth

• Connection first: wired LAN, then the same router, then a nearby 5 GHz Wi-Fi signal. Your internet speed is irrelevant — this stream never leaves your house until Discord carries your share. If it stutters, our lag and desync fixes apply word for word.
• Nothing to unlock: the feed is 720p30, which fits Discord’s standard Go Live quality — a paid tier can’t make the source feed higher, because the console itself sends 720p30.
• Black window? You shared before launching a game, or you’re on the Home menu — system screens aren’t streamed. Launch the game first; if it persists, see the black screen fixes.

What this setup honestly is

This is the fastest free way to put a Switch game in front of friends — co-watching a run, showing a build, playing pass-the-controller party games. It’s a 720p30 feed, so treat it as hanging out, not broadcasting: when you’re ready for a public channel with scenes, alerts and recordings, the same feed plugs into OBS properly in our Twitch & YouTube streaming guide, and our capture card comparison shows what hardware adds beyond that.

Troubleshooting the share

• Friends see a black window: the game isn’t running yet, you’re on the Home menu (never streamed), or you picked the wrong window in the Applications list. Launch the game, then re-share the SysDVR-Client window specifically — not your whole screen, which also protects your privacy.
• Friends hear the game but it’s choppy: that’s the console-to-PC hop, not Discord. Move up the connection ladder — LAN over router over nearby 5 GHz — and prefer the client modes (USB/TCP Bridge) over watching an RTSP player and sharing that.
• Your mic echoes the game: your speakers are feeding your microphone. Headphones fix it completely and take five seconds.
• The share option is missing or limited: you’re in the browser version of Discord. The desktop app is where application-window sharing with audio actually lives.
• Can I do this from the Android client instead? This guide is deliberately the PC route — Discord’s sharing features are at their fullest on desktop. The phone shines as a monitor for your own play, not as the broadcast source.

One setting worth touching: in Discord’s Go Live dialog, choose the 720p / 30fps option (the “smoother video” style preset) rather than anything higher. The source feed is 720p30, so a higher share setting buys nothing but extra upload bandwidth and encoding load — matching the share to the source is the whole trick.

Next steps

• Record clips & screenshots with SysDVR — save the session while you share it.
• TCP Bridge mode — the low-latency network mode behind Route A.
• Use your Android phone as a Switch monitor — the same trick, away from the desk.

The ceiling every method shares

SysDVR streams the console’s built-in recording feed: 720p30 H.264 video with 16-bit PCM 48 kHz audio. Recording captures that feed as it arrives — no method on this page can add detail the console never sent, and nothing upscales it into real 1080p. Within that ceiling, though, recordings are clean, and 720p is a perfectly serviceable format for clips, Discord shares and most video platforms.

Method 1 — The client’s built-in capture (quickest)

Since version 6.0, the SysDVR-Client GUI can capture video clips and screenshots in real time while the stream is running — press the capture controls in the client window when something worth keeping happens, and the clip or still is saved without any other software in the chain. Because it works inside the client, it works the same over USB, TCP Bridge and on the Android app.

There’s a command-line equivalent too: v6.3 reintroduced the --file option, which records clips from the terminal — handy for scripted or repeatable captures. Run SysDVR-Client --help for its exact syntax on your build.

Best for: spontaneous clips while playing — a boss kill, a glitch, a goal — with zero setup.

Method 2 — OBS recording (best if you also stream)

1. Add the stream to OBS: either a Window Capture of the SysDVR-Client, or a Media Source pointed at rtsp://<console IP>:6666/ in Simple Network mode (untick “Local File”). The media source adds some buffering, which is fine for recording even if it’s not ideal for live play.
2. Make sure OBS is hearing the game — check the audio meter moves with the game’s sound.
3. Press Record. Your overlays, webcam and scene layout are baked into the file, ready to upload.
4. For a still, use OBS’s screenshot of the preview/source — or grab the frame with the client’s own screenshot capture instead.

This is the route to build on if recording is a habit: one OBS setup serves both this and streaming to Twitch and YouTube.

Method 3 — mpv stream recording (no client at all)

In Simple Network mode you can skip the client entirely. Play the feed in mpv with the usual low-latency flags, and add mpv’s stream-record option to save it at the same time:

mpv rtsp://<console IP>:6666/ --profile=low-latency --stream-record=clip.mkv

Two honest warnings from mpv’s own manual: stream recording remuxes without re-encoding, and mpv calls the feature fragile and experimental — files can occasionally come out broken. Use the .mkv container, and test with a short clip before trusting it with a long session. (On older mpv builds the same option was named --record-file.) Our RTSP mode guide has the full low-latency flag set and the TCP/UDP transport choice.

A note on screenshots

Whichever tool takes them, screenshots are frames of a 720p video feed. They’re great for sharing moments, thumbnails and bug reports — just expect video-frame quality rather than crisp UI stills, especially with small text.

Quick picker

Set up once for clean captures

• Record through the client modes when you can. The built-in capture works in the client itself, so USB or TCP Bridge gives you clip capture with the least machinery between the game and the file. The RTSP routes work too, but they add a player and its buffering into the chain.
• Do a 20-second test clip and play it back before the real session — on the machine you’ll edit or share from. You’re checking two things: picture, and that the audio plays natively (on v6.3’s AAC clips it will; on older clients this test is exactly where a conversion surprise shows up).
• Keep versions matched. Capture features arrived and changed across 6.x — the GUI capture in 6.0, the AAC improvement and --file‘s return in 6.3. A console and client on the same current release is what makes this page’s instructions true. Updating both sides takes five minutes.
• Clip has no sound or won’t play on Windows? You’re almost certainly on a pre-6.3 client. Update, re-record the test clip, and the AAC change should make it play as-is.

Short clips or full sessions?

Pick by session shape as well as by tool. The client’s built-in capture is built around moments — something happens, you grab the clip. For recording an entire play session start to finish, OBS or mpv are the natural fit: they write one continuous file for as long as you play, OBS with your full layout on top. Plenty of creators run both at once — OBS recording the session, the client capture ready for the highlight that deserves its own file.

Next steps

• Stream to Twitch & YouTube with OBS + SysDVR — the same OBS setup, live.
• Simple Network (RTSP) mode — the feed behind methods 2 and 3.
• Make sure you’re current: files and release notes are on the SysDVR download page.