The fix is simply to hand the interface over: take SysDVR out of USB mode (or offline) before you use USB homebrew, and switch back when you are done. How you do that depends on which SysDVR build you run.

Why this happens

SysDVR is a sysmodule — a background service that starts with the console and stays resident. In USB mode it claims the USB connection for streaming video and audio to your PC. Goldleaf (for installing and managing files over USB), nxmtp (MTP file access) and Twili use that same USB channel to talk to the computer. The console cannot split it, so the homebrew loses. Network modes do not touch USB, which is why this conflict only exists in USB mode.

Full SysDVR build: switch modes in the Settings app

1. Open the SysDVR Settings app on the console.
2. Change the streaming mode away from USB — pick a network mode (TCP Bridge or Simple Network), or use Go Offline to stop streaming entirely.
3. Launch Goldleaf, nxmtp or your other USB homebrew and use it as normal.
4. When you are finished, return to the Settings app and switch back to USB mode to stream again.

No reboot is needed on the full build: since v6.2.1 the sysmodule can start and stop without restarting the console, and mode switching happens in the app. Our Settings app explained post covers each option.

USB-Only build: disable the sysmodule and reboot

The USB-Only build has no Settings app, so there is nothing to switch in the moment — on this build you cannot use USB homebrew at the same time at all. To free the interface, disable the SysDVR sysmodule (its mode is set through the config files on the SD card; remove the USB configuration), then reboot the console. Use your USB homebrew, then restore the configuration and reboot again to stream. If you regularly alternate between streaming and USB file tools, the full build’s in-app mode switch is much less painful — both builds are on the download page, and the install guide compares them.

A workable routine

• Do your file management first (Goldleaf / nxmtp), then switch SysDVR back to USB and stream.
• Keep the console undocked for both jobs — SysDVR USB streaming does not work docked anyway.
• If USB homebrew still fails after SysDVR is offline, unplug the cable for a few seconds and reconnect; if Windows then complains about the device, the driver side is covered in USB device not recognized.

Which tools are affected — and which are not

The official troubleshooting notes name Goldleaf, Twili and nxmtp, and the rule generalises: anything that talks to the PC over the console’s USB connection competes for the same interface. Tools that work over the network instead are unaffected — and so is SysDVR itself in its network modes. That gives you a genuinely comfortable option if you use USB homebrew often: leave SysDVR in TCP Bridge mode as your daily default, stream over your local network, and keep the USB port free for file tools permanently. Reserve USB streaming for the sessions where its lower latency actually matters to you.

And to be clear about the stakes: this conflict cannot damage anything. No files are corrupted, no installs are half-written by SysDVR’s presence — the homebrew simply cannot open a channel that is already taken. The moment the interface is free, everything works again, which is also your simplest diagnostic: if Goldleaf works the instant SysDVR goes offline, you have confirmed the cause beyond doubt.

“Can I use both at the same time?”

Over USB, no — one interface, one owner, no exceptions. But there is a combination that genuinely works in parallel: stream with SysDVR in a network mode while your USB homebrew uses the cable. Network streaming never touches the USB interface, so Goldleaf and nxmtp behave as if SysDVR were not installed, while TCP Bridge carries your stream over the local network. For most people this is the real long-term answer rather than a workaround: network streaming for everyday play, USB homebrew whenever you need it, and USB streaming only on the occasions that demand its latency.

One related misunderstanding to clear up: closing the SysDVR Settings app does not free the interface. The app is just a control panel — it is the resident sysmodule that holds USB, and it holds it until you change the mode or take it offline in that app (or, on USB-Only, disable it and reboot). Quitting the app, or quitting the PC client, changes nothing on the console side.

Still stuck?

If Goldleaf or nxmtp still will not launch after SysDVR is offline (or disabled and rebooted on USB-Only), the cause is elsewhere — check that no other sysmodule is claiming USB, and that the tool itself is current for your firmware. Ask in the project Discord or open a GitHub issue with your build (full or USB-Only) and mode. More guides are on the troubleshooting hub, including the full USB streaming setup.

Work through the checks in order; each takes under a minute.

Check 1: Is the game actually sending audio right now?

SysDVR audio rides the same capture pipeline as the video. In games or sections where recording is restricted, you can lose audio along with (or even without obviously losing) video. Test with the capture button in a known-friendly spot: if long-pressing capture records a clip with sound, the console side is producing audio and the problem is downstream. If a particular game never has sound anywhere, check whether it needs dvr-patches — see installing dvr-patches and which games work.

Check 2: Player and client volume / output device

The boring one, and the most common fix. Confirm the SysDVR-Client (or your player) is not muted, its volume is up, and — on Windows — that it is routed to the output device you are actually listening to in the system volume mixer. If you recently plugged in or removed headphones or a headset, players often keep sending audio to the device that existed when they started; restart the client after changing outputs.

Check 3: RTSP players — select the audio track

Watching via Simple Network (RTSP) mode in mpv or VLC? Players can start with no audio track selected or the wrong one. In your player, check the audio track menu and explicitly select the stream’s audio track, and confirm the player is not set to a muted or “no audio” output. The recommended low-latency mpv setup is in the RTSP mode guide. In OBS, also check the media source is not muted in the audio mixer.

Check 4: Silence vs desync — pick the right fix

If you can hear the audio but it is early or late, that is a sync problem, not this one: the “Disable Audio/Video sync” setting trades latency against sync, and toggling it plus improving your connection is the cure in the lag and desync guide. True silence is unaffected by that toggle, so if flipping it changes nothing, come back to this checklist.

Check 5: Match versions and reboot

A sysmodule and client on mismatched versions can produce a stream with video but broken or missing audio. Bring both sides to the same release from the download page and reboot the console — sysmodules only reload at boot. The routine is in how to update SysDVR.

Check 6: Linux users — never run the client as root

A very specific one from the official notes: on Linux, running SysDVR-Client as root breaks audio. Use the udev rule (99-sysdvr.rules) so the client can access the console as your normal user instead — see the Linux client setup.

Check 7: Isolate with USB mode

Switch the console to USB mode and listen through the client over a cable (needs the one-time driver install from the client’s USB Driver menu). If audio plays over USB but not over the network, your console and game are fine and the fault is in the network path or the network player. If USB is silent too, the problem is on the console side or the game itself.

Check 8: Is the console itself making sound?

Undock the console and listen to the game on its own speakers. If the game is silent on the console itself, SysDVR has nothing to send and the problem is the game or its settings (an in-game music/effects slider, a muted cutscene track), not the stream. If the console sounds fine but the PC stays silent, work back through Checks 2, 3 and 5 — the audio is being produced and lost on the receiving side.

Special case: recorded clips with no sound

If your live stream has audio but clips recorded with the client’s built-in recording play back silent in your media player, that is a file-format issue, not a stream issue. Since v6.3, SysDVR records clip audio in AAC specifically so the files play on Windows without conversion — so if your recordings are silent, first make sure you are actually on v6.3 on both sides (see Check 5), and try a current player before assuming the recording failed.

Audio that cuts in and out is a different problem

Do not confuse silence with dropouts. If the sound is there but chops, crackles or vanishes for seconds at a time, the pipeline is fine and the delivery is not — that is connection quality, the same territory as video stutter. Wired LAN, same router, close 5GHz, in that order of preference; the full treatment is in the lag and desync guide. Run the checks on this page only when there is no audio at all, ever, from the first second.

Still stuck?

Note the game, mode, player/client and both version numbers, then ask in the project Discord or open a GitHub issue. More symptom guides are on the troubleshooting hub, including the black screen fix — the mirror image of this problem.

The good news: since the USB rewrite in v5.5, the driver installs from inside SysDVR-Client itself. If an old guide sent you to Zadig, close that tab — that method is legacy, and the official Wiki is explicit that anyone who set things up the pre-5.5 way must redo it with the current method.

The current method: install the driver from the client

1. On the console, open the SysDVR Settings app and set the streaming mode to USB (with the USB-Only build, USB is already the only mode).
2. Connect the console directly to the PC with a USB-A to USB-C cable. USB-C to USB-C cables are known to be unreliable for this — and USB streaming does not work while the console is docked, so plug in undocked.
3. Launch SysDVR-Client on the PC, open the USB Driver option in the main menu, and click Install.
4. Wait for the install to finish, then unplug the console for a few seconds and reconnect it.
5. Start the client in USB mode and connect — the console should now be detected.

Do not be alarmed by how Windows names the device after the driver install: the console shows up as an Android-type device, on some systems listed as “Google Inc. Nexus/Pixel (fastboot)”. That is expected — SysDVR’s USB interface presents itself that way, and it is exactly what the driver is for.

Fallback: install Google’s ADB driver manually

If the built-in installer fails on your system, the official manual fallback is Google’s Android USB driver:

1. Download the Android ADB USB driver from Google and extract the archive to a folder.
2. Inside it, open the usb_driver folder and find android_winusb.inf.
3. Right-click android_winusb.inf and choose Install.
4. Unplug the console for a few seconds, reconnect, and retry the client.

About Zadig: why old guides are wrong now

Pre-5.5 versions of SysDVR required replacing the driver with WinUSB using the Zadig tool. The USB stack was rewritten in 5.5 and that procedure no longer applies — following it today is a common reason USB stays broken. Everything current is described in the USB streaming setup guide; get the latest client and sysmodule from the download page and use the built-in installer above.

Console charges but never appears? Suspect the cable

A classic trap: the Switch charges happily over the cable, so the cable must be fine — except charge-only USB cables exist, and they carry power with no data lines at all. If the console charges but no device ever shows up, try a different cable before reinstalling anything, ideally a short, known data cable. The same applies in reverse while troubleshooting the driver: a cable that drops data intermittently can make a perfectly installed driver look broken. One known-good USB-A to USB-C data cable, plugged straight into the PC, is the reference setup for every test in this guide.

More than one console? Use –serial

If several Switch consoles are attached, the client can be pointed at a specific one from the command line: SysDVR-Client.exe usb --serial <serial>. Without it, the client may attach to a different console than the one you are troubleshooting.

Before blaming the driver: three quick sanity checks

• Is the console actually in USB mode? On the full build, check the mode in the SysDVR Settings app — a console left in a network mode is invisible to USB no matter how good the driver is. (On the USB-Only build USB is the only mode, so skip this.)
• What does Device Manager say? After the built-in install, the console should appear as an Android-type device. If it shows as an unknown device with a warning icon, the driver install did not take — re-run the client’s USB Driver install, unplug for a few seconds, and reconnect. If the listing appears only while the console is awake at the Home menu with a game running, that is normal stream behaviour, not a driver fault.
• Did it work before an update? If USB detection broke right after updating SysDVR, install the current client and sysmodule as a matched pair from the download page and run the driver install once more — driver state from an old client version is a recurring cause of “suddenly unrecognized”.

Also try a port on the PC itself rather than a front-panel or hub port, and a second cable before you conclude anything: for a problem that looks exactly like a driver failure, the physical layer is guilty surprisingly often.

On Linux it works differently

Linux does not use this driver flow at all: USB mode there relies on libusb plus a udev rule (99-sysdvr.rules), and the client must not be run as root — doing so breaks audio. macOS and Android receivers need no driver setup. Details are in the Linux client setup.

Still stuck?

If the device is still not recognized after the built-in install and the manual fallback, try a different USB-A to USB-C cable and a different port (cable quality genuinely matters here), confirm the console is in USB mode, and make sure console and client versions match. If it persists, ask in the project Discord or open a GitHub issue with your Windows version and what Device Manager shows. Related: Goldleaf and nxmtp conflicts over the same USB interface, and the rest of the troubleshooting hub.

One myth to drop immediately: your internet speed is irrelevant. SysDVR network streaming is entirely local — what matters is the signal and path between the Switch and the receiving device, nothing upstream of your router.

Fix 1: Toggle “Disable Audio/Video sync” in the client

SysDVR-Client has a setting to disable A/V sync. With sync enabled, the client holds audio and video together, which adds latency and can turn small connection hiccups into visible stutter. Disabling sync reduces latency and smooths out glitchy video — the trade-off named in the official notes is that audio may drift out of sync. So treat it as a lever, not a permanent answer:

• Video lags or glitches: disable A/V sync and see if the picture smooths out.
• Audio is ahead of or behind the picture: try the opposite state — re-enable sync if you disabled it, and improve the connection (Fix 2) so sync no longer costs you stutter.

Fix 2: Climb the connection hierarchy

Local connection quality decides everything. From best to worst:

1. Wired LAN for the console (dock with a LAN adapter, PC wired too) — the most stable option.
2. Console and PC on the same router, close to it.
3. Near 5GHz Wi-Fi — acceptable when you are close to the router; distant or congested Wi-Fi is where stutter lives.

Move the console and PC closer to the router, get both onto the same network, and avoid public or heavily shared Wi-Fi. “Wired” for a Switch means the dock’s built-in LAN port (on the OLED dock) or a USB LAN adapter in the dock — it removes Wi-Fi from the console’s half of the path entirely, which is the half that usually suffers. If you use TCP Bridge mode, that is already the lowest-latency network mode. And if you are on 2.4GHz Wi-Fi because it “reaches further”, try 5GHz anyway: for a stream this small, a clean short-range 5GHz link beats a strong but crowded 2.4GHz one almost every time.

Fix 3: RTSP delay that grows over time is a cache problem

In Simple Network (RTSP) mode, players like mpv use a cache buffer to ride out dropped packets — and that buffer slowly turns into delay, so the stream feels fine at first and seconds late after a while. Use mpv’s low-latency flags (--profile=low-latency --no-cache --cache-secs=0 --demuxer-readahead-secs=0 --cache-pause=no) as covered in the RTSP mode guide. OBS as a media source adds its own buffering delay on top — expect a little, always.

Quick reference: symptom to fix

Fix 4: Use USB mode as the zero-network test

Want to know in one minute whether your network is the problem? Switch SysDVR to USB mode and stream over a cable with the USB setup. USB is the lowest-latency mode and removes the network entirely. If USB is smooth, your sysmodule and client are healthy and every remaining problem is your local network path. If USB also stutters, look at the PC side — decoder choice and hardware acceleration, covered in the advanced tips post.

RTSP transport: UDP for latency, TCP for stability

If you watch in Simple Network mode with mpv, the transport protocol is a real lever: mpv can pull the RTSP stream over UDP or TCP (--rtsp-transport=udp). UDP skips retransmission, so delay stays minimal — but every dropped packet on a lossy Wi-Fi link shows up as a glitch or a freeze. TCP delivers everything, which looks cleaner on a weak signal, at the cost of extra delay when packets need resending. On a solid connection, UDP is the low-latency choice; on a marginal one, TCP plus the no-cache flags is often the smoother watch. Try both — the better one depends entirely on your room, not on the console.

Glitches point at the link, stutter points at sync

Learn to read the failure, because the two big symptoms have different owners. Random visual glitches and artifacts mean data is arriving damaged or late — that is the connection, and only the hierarchy in Fix 2 (or the USB test in Fix 4) cures it. A picture that is smooth but consistently behind, or that judders in a steady rhythm, is the client managing sync and buffering — that is Fix 1 and Fix 3 territory. Chasing the sync toggle for a glitching picture, or rewiring your network for a rhythmically juddering one, wastes an afternoon; match the fix to the symptom.

Still stuck?

If lag survives a wired connection and the sync toggle, note your mode, connection type, and both SysDVR versions, then ask in the project Discord or open a GitHub issue. Related guides on the troubleshooting hub: client can’t find the console and no audio at all (different problem from desync — silence has its own checklist).

The recovery below is safe and reversible. It isolates whether SysDVR triggers the failure, trims the sysmodule load, and gives your console the breathing room to boot again.

Step 1: Remove SysDVR to confirm the trigger

Power the console fully off, take out the microSD card and open it on a PC. Delete (or rename) the SysDVR folder:

/atmosphere/contents/00FF0000A53BB665

Put the card back and boot. If Atmosphère starts normally, SysDVR’s addition tipped a memory-starved setup over the edge — continue to Step 2. If it still will not boot, the problem is elsewhere in your Atmosphère setup: skip to Step 4.

A note on technique: renaming instead of deleting is the safer isolation move. Rename the folder to something like 00FF0000A53BB665-off and Atmosphère will skip it, because sysmodules load by their exact folder name. If the boot succeeds, rename it back later once you have freed memory elsewhere; if you deleted instead, you can always re-extract the folder from a fresh SysDVR.zip. Either way, do not reach for the nuclear option in Step 4 until this test has told you whether SysDVR is even involved.

Worked yesterday, broke today? Think about what changed

Boot failures after installing SysDVR almost always have a trigger, and naming it speeds the recovery. The three usual ones: you added another sysmodule recently (the pool was already nearly full), you updated firmware or Atmosphère (which changes both the memory picture and what a stale sysmodule build can survive), or you updated SysDVR by itself and left an old client or an old companion module behind. Recovery time is short in all three cases — the isolation test above takes five minutes with a PC, and even the clean-slate route is under half an hour. Nothing in this failure mode touches your games, saves or accounts.

Step 2: Trim your other sysmodules

Every folder inside /atmosphere/contents/ is a sysmodule that loads at boot and eats from the same small memory pool. Remove or disable the ones you do not actively need — sys-ftpd is named in the official troubleshooting notes as a particularly heavy one — then restore the SysDVR folder and boot again. Many setups run fine once one heavy module is gone. And if the failure began right after a firmware or Atmosphère update rather than after adding a module, suspect a stale sysmodule build first — refresh SysDVR to the current release before assuming your setup is simply too heavy.

Step 3: Switch to the USB-Only build

If you really need your other sysmodules at the same time, use the USB-Only version of SysDVR. It uses roughly 500KB of memory against slightly under 1MB for the full build, which is often the difference between booting and not booting. The trade-off: it streams over USB only and has no Settings app. Both builds are on the download page, and the install guide explains choosing between them.

Step 4: The clean-slate option

If Atmosphère still refuses to boot with SysDVR removed, or you are not sure which folder belongs to which sysmodule, the official fallback is blunt but effective: delete the whole /atmosphere folder, download a fresh copy of Atmosphère, and set it up cleanly before adding SysDVR back. Your games and saves are not in that folder, so this costs you setup time, nothing else. Add sysmodules back one at a time afterwards so you learn exactly which combination breaks the boot.

Why sysmodule memory is so tight

Sysmodules do not get to use the console’s normal application memory. They share a small reserved pool set aside for background services, and everything in your atmosphere/contents folder draws from it at once: streaming, FTP servers, overclocking tools, controllers support, cheats infrastructure. Each one is small — SysDVR’s full build is slightly under 1MB — but the pool is smaller than people expect, and Atmosphère itself refuses to boot when the pool cannot satisfy everything that asks at startup. That is why a setup can work for months and then break the day you add one more module: nothing was wrong with any single piece, the total simply crossed the line. Firmware updates change the memory picture too — sysmodule memory was reduced on firmware 20.0 and newer, so a stack that fit comfortably on older firmware can stop fitting after an update you barely noticed.

A practical habit: keep a backup copy of your working contents folder on your PC. When a boot failure happens, you can restore the last known-good set in one copy operation instead of playing folder roulette, then re-add modules one at a time.

Preventing it next time

• Keep the sysmodule count lean — if you do not use it every session, it does not need to load at every boot.
• Update Atmosphère and SysDVR together, and always reboot after updating either; a stale sysmodule against a new Atmosphère is a classic boot-failure recipe. See how to update SysDVR.
• Prefer the USB-Only build on crowded setups.

Still stuck?

If a clean Atmosphère install plus SysDVR alone still will not boot, record your firmware version, Atmosphère version and SysDVR version and ask in the project Discord or open a GitHub issue. More recovery guides live on the troubleshooting hub, including the Settings “not running” fix for consoles that do boot but never start the sysmodule.

The most likely cause of “outdated” is just as mundane: you updated the files on the SD card but never rebooted, so the old sysmodule is still the one loaded. Here is how to clear both messages for good.

“Not running”: wait out the 20-second startup

Do this first, before changing anything: reboot the console, wait a full 20–30 seconds on the Home menu, then open the Settings app again. In the overwhelming majority of cases the warning is gone and the app connects normally. The sysmodule is a background service; it is simply not ready the instant the Home menu appears.

Using the USB-Only build? There is no Settings app support

The lightweight USB-Only version of SysDVR does not support the Settings app at all — that is by design, not a fault. Its streaming mode is fixed to USB and configured through files on the SD card instead of the app, and its smaller memory footprint (roughly 500KB) is the trade-off. If you want the Settings app, install the full SysDVR.zip instead; both are on the download page. Our Settings app explained post walks through everything the app offers.

“Outdated”: you updated the files but not the running sysmodule

Sysmodules are loaded from the SD card only at boot. Copying a new SysDVR version over the old one changes nothing about what is currently running — the console keeps using the version it booted with, and the Settings app (or the PC client) notices the mismatch and reports “outdated”. The fix is a single reboot. After any SysDVR update, on either side, restart the console before testing.

Console and client versions must match exactly

The outdated warning also appears when the console and the PC client are simply on different releases. Check the version shown in the Settings app against your SysDVR-Client release, and bring both to the same version. Our update guide covers the two-sided routine; the key rule is: update the sysmodule files and the client, then reboot the console.

What these messages actually mean

It helps to know what the Settings app is doing. SysDVR the sysmodule is a background service that loads with Atmosphère and runs whether or not you ever open the app. The Settings app is a separate small program — it ships inside SysDVR.zip as switch/SysDVR-conf.nro — whose job is to connect to that service, show its status and version, and let you change the streaming mode. “Not running” means the app could not reach the service: either it has not finished starting (the 20 seconds), it is the USB-Only build where this pairing does not exist, or the service never loaded. “Outdated” means the app reached the service and the version it found is not the version it expects — almost always a reboot that never happened after an update.

Two corollaries worth knowing. First, if the Settings app itself is missing from your homebrew menu, the zip was not extracted completely — re-extract SysDVR.zip to the root of the SD card so both the atmosphere/contents folder and the switch folder land in place, then reboot. Second, since v6.2.1 the sysmodule can be started and stopped from the Settings app or a toolbox without rebooting, so once the app connects, mode changes and restarts of the service are quick — the only hard reboot requirement is after replacing the files themselves.

How to compare the two version numbers

When in doubt, check both sides explicitly instead of guessing:

1. On the console, open the SysDVR Settings app — once it connects, it displays the sysmodule version it found. If it will not connect at all, that itself is the “not running” case above.
2. On the PC, the client version is the release you downloaded and extracted. If the folder has been sitting around through a few updates, you may honestly not know — in that case stop guessing.
3. Download the current release once from the download page and install both halves of that same version: sysmodule files on the SD card, client on the PC. Reboot the console. Now the versions match by construction, and any remaining warning is a real signal instead of version fog.

Note that updating only the client can trigger “outdated” just as updating only the console can — the warning compares the pair, and it fires when either side moves alone.

Still “not running” after a proper wait?

1. Remove the microSD card and confirm the SysDVR folder is actually in place: /atmosphere/contents/00FF0000A53BB665 should exist with the files extracted from SysDVR.zip (not the zip itself, and not a doubled-up folder).
2. Check for other heavy sysmodules: too many of them can stop SysDVR from starting at all — the same conflict behind Atmosphère boot failures.
3. If the install is still not detected, the official advice is to reinstall Atmosphère fresh and then SysDVR on top — an old Atmosphère build or a messed-up SD setup is the usual remaining cause.

Still stuck?

Note the exact message, your SysDVR version, your Atmosphère version and whether you run the full or USB-Only build, then ask in the project Discord or open a GitHub issue. Meanwhile the troubleshooting hub collects the related guides, including client can’t find the console — a frequent companion problem to a sysmodule that is not actually running.

If the picture never appears at all, the next suspects are a game that blocks video recording, or you are looking at a screen SysDVR can never capture — the Home menu and system UI are not streamed, ever. Go through the causes below in order.

Fix 1: Wait, then move the game camera

After connecting, give the stream a few seconds. Especially in games where the screen is mostly static — 2D platformers are the classic example — a keyframe can take a while to show up. Moving the game camera or character forces the console to emit new frames and usually makes the picture pop in. If video appears after movement, nothing was wrong.

Fix 2: Run the capture-button test

SysDVR streams through the console’s built-in video recording feature, so it can only show games that support it. The test takes five seconds: in the game, long-press the capture button. If the console can record a clip, the game is compatible and the black screen comes from something else on this list. If recording is blocked, SysDVR gets no video from that title — some games only allow capture in certain sections, so streaming works there and goes black elsewhere.

For games that block recording, the author of SysDVR maintains a separate patch set called dvr-patches that can unlock streaming for many of them. It must match your console firmware, and a small number of games still will not work properly. See installing dvr-patches and our game compatibility overview.

Fix 3: Launch a game — the Home menu is never captured

The system UI, Home menu, console settings and homebrew launched as applets are not captured by SysDVR at all; they always show as black or blank. If you connected before starting a game, that is your answer: launch a compatible game and the stream begins. For the technical background, the Settings app explained post covers what the sysmodule can and cannot see.

Fix 4: Homebrew needs title takeover

Homebrew launched through the album applet will not stream. To stream homebrew, use title takeover: hold R while launching a compatible game so the homebrew runs in its place with full permissions — then it is captured like a game.

Fix 5: Match versions and reboot

A console sysmodule and client on different versions can connect oddly or produce no video. Make sure both sides run the same release (the current one is on our download page) and reboot the console after updating, because sysmodules reload only at boot. The full routine is in how to update SysDVR.

Fix 6: If you watch through RTSP or OBS, check the player

In Simple Network mode, some players buffer aggressively or sit on a black frame while filling their cache. mpv with the low-latency flags is the recommended player — see the RTSP mode guide. OBS used as a media source adds its own buffering delay, so a black OBS source for the first seconds is normal; give it time before assuming failure. Also confirm the mode selected in the SysDVR Settings app matches how you are trying to watch.

Only one game is black, the rest are fine

Take that as good news: your install, versions and network are all healthy, and the problem is that specific title. Some games allow video capture only in certain sections — menus, cutscenes or particular modes — so the stream works in one part of the game and goes black in another, in a pattern that repeats exactly. That is the capture restriction working as designed, and the dvr-patches route in Fix 2 is the only lever that changes it. If the same game is black everywhere while others stream, it is simply an unsupported title.

Sound but no picture? That narrows it down

If you can hear the game’s audio while the window stays black, the stream itself is connected and flowing — only the video side is stuck. That rules out discovery, network and version problems and points squarely at the causes above: a keyframe that has not arrived yet, a player holding an empty buffer, or a game section where video capture is blocked while audio still passes. Work Fixes 1, 2 and 6 and ignore the rest.

Mode mismatch: the silent setup error

Finally, confirm the console is in the mode you think it is. If the SysDVR Settings app is set to USB while you open the network client (or the other way around), you can end up staring at a black or empty player with no error anywhere. Switching modes takes seconds in the Settings app and applies to the full build without a reboot. While you are there, glance at the running state: if the sysmodule reports it is not running yet, you are looking at the 20-second startup wait covered in the Settings “not running” guide, not a video problem at all.

Still stuck?

If a capture-compatible game still shows black after a keyframe wait, a version check and a reboot, capture the details (game title, mode, both version numbers) and ask in the project Discord or open a GitHub issue. You will find more symptom-based guides on the troubleshooting hub — including video but no audio and lag and stutter.

The most likely cause is a version mismatch between the SysDVR sysmodule on the console and SysDVR-Client on your PC — the two must be exactly the same version or the connection fails. Close behind are a firewall blocking the client, a no_adv file silently disabling discovery, and routers that isolate devices from each other. Work through the fixes below in order; most people are streaming again within the first three.

Before you start: the 60-second checklist

• The console is powered on, connected to the same network as the PC, and a game is running (SysDVR only streams gameplay).
• You rebooted the console after installing or updating SysDVR — sysmodules only load at boot.
• SysDVR-Client was allowed through Windows Firewall when it asked (this matters for network discovery).
• No VPN is active on the PC — VPNs routinely swallow local broadcast traffic.

Fix 1: Reboot the console after any install or update

Sysmodules are loaded when Atmosphère boots, not when you copy files to the SD card. If you installed or updated SysDVR and never restarted, the old version (or nothing) is what is actually running, and the client will not pair with it. Reboot the console, wait about 20 seconds for the sysmodule to start, then relaunch the client.

Fix 2: Make the console and client versions match

Open the SysDVR Settings app on the console to see the sysmodule version, and compare it with the client release on your PC. If they differ, update both sides from the same release — grab the current version from our download page and follow the steps in how to update SysDVR. Remember to reboot the console after replacing the files.

Fix 3: Confirm both devices are really on the same network

Auto-discovery only works on the same local network segment. Check the console’s IP address in its internet settings and make sure the PC is on the same router and the same network — not a guest Wi-Fi network, which typically blocks device-to-device traffic. Public hotspots and some routers enable AP/client isolation, which makes discovery impossible no matter what you change on either device; if you suspect isolation, test on a different network or use manual IP entry (Fix 5).

Fix 4: Let the client through the firewall and drop the VPN

On Windows, the firewall prompt when you first launch SysDVR-Client is not a formality — denying it can block the discovery broadcast. Allow the client on private networks, or add it as an exception manually. If you run a VPN on the PC, disconnect it while streaming: local traffic routed into the tunnel never reaches the console. Third-party security suites can block it too; whitelist the client there as well.

Fix 5: Enter the console’s IP address manually

If discovery keeps failing, skip it: the client supports manual connections, and since v6.3 it remembers the last manually entered IP, so you only type it once. Find the console’s IP in its internet settings, enter it in the client’s manual connection option, and connect. This bypasses broadcast problems, no_adv files and most router quirks in one move.

Fix 6: Check for a no_adv file

Auto-discovery can be deliberately switched off by placing an empty file at /config/sysdvr/no_adv on the SD card. If you (or a pre-made SD setup) created that file, the console never advertises itself and will never appear in the client list — you can still connect by manual IP. Delete the file and reboot if you want discovery back. The advanced tips post covers this flag in more detail.

Fix 7: Isolate the problem with a different mode

Still nothing? Test another path to learn where the failure lives. Try Simple Network (RTSP) mode with a player such as mpv pointing at the console’s IP, or connect over USB following the USB streaming setup. If RTSP works, your network path is fine and the issue is specific to discovery; if USB works, the sysmodule is healthy and the problem is definitely on the network side.

Know which discovery you are actually using

One distinction saves a lot of confusion: only TCP Bridge mode has discovery at all. In that mode the console advertises itself and the client lists what it hears. Simple Network (RTSP) mode has no list and nothing to “find” — you always connect directly to the console’s IP address, so a failure there means a wrong IP or a blocked path, not a discovery problem. And if the console is set to USB mode in its Settings app, it will never appear on the network: the mode on the console and the mode in the client have to match. Check that first whenever a previously working setup suddenly goes quiet — a mode left on USB after a wired session is a classic.

Still stuck?

If the client still cannot see the console after all of the above, note down both version numbers, the mode you are using and your network setup, then ask in the project Discord or open a GitHub issue — the official support channels linked from the project Wiki. Reports with exact versions get answers much faster. More fixes live on our SysDVR troubleshooting hub, including the Settings app showing “not running” and black screen guides.