Strange functionality issues with SysDVR on near-recent AMS/HOS

[ToxiClay]

[To submit a bug report fill all the parts of the template, then remove all the text within square brackets "[ ]" ] [Issues that don't follow the template will be closed]

Describe the bug SysDVR not functioning with AMS 1.4.0 and HOS 15.0.0.

To Reproduce

1. Have AMS 1.4.0 and HOS 15.0.0 installed
2. Launch a game
3. Attempt to stream with any mode. The precise failure depends on which mode you use:

In USB Capture Mode, it will appear to function, but nothing appears in the player.

In TCP Bridge Mode, it's more up-front about its failure.

In Simple RTSP Mode, I get a single frame of video. Reopening the player to the same RTSP stream caused it to start working, though with some lag that I can't tell if it's normal.

Afterwards, both USB and TCP Bridge modes started working for a bit, then stopped again.

Expected behavior [A clear and concise description of what you expected to happen.]

Setup information

• PC OS: Windows 10 version 21H2 Build 19044.2130
• Console firmware: HOS 15.0.0
• Custom firmware name and version: Atmosphere 1.4.0
• SysDVR 5.2
• Microsoft .NET SDK 6.0.201

Additional context

I: is an external USB Western Digital hard drive.

After starting to work, then stopping:

[exelix11]

I believe you have different versions of sysdvr and the client app. Download latest of both and reboot your console.

[ToxiClay]

OK, sysmodule and client updated; I'm not sure if the sysmodule was different. There's a change, but not a good one; I'm not sure what it means.

It's seeing my Switch's serial number, so it's sensing the device, but it's refusing to connect for some reason.

[exelix11]

did you reboot the console after updating and are you running a compatible game ?

[ToxiClay]

I hard shutdown the console and brought it back up, yeah. I'm running a game called Dungeon Encounters from the eShop; I don't see a particular reason why that title would be incompatible, but let me try Atelier Sophie 2, a title that I know has worked in the past.

No change, even when trying a different USB cable and port. I don't know how to restart SysDVR outside of restarting my console, otherwise I'd definitely try that.

[exelix11]

rebooting the console is fine.

If the game is compatible then you're facing two different issues: one over network and one over USB. For USB try reinstalling the driver from the GUI then unplug your console. Regarding network i noticed that your ip address .50.2 is not common, if you're connected to a public hotspot the owners may have disabled communication between local devices which is needed to stream with sysdvr.

You can read more driver in the troubleshooting page about reinstalling the usb driver, including a guide for manual installation.

[ToxiClay]

Zadig reported that the WinUSB drivers were installed and at their appropriate versions, but I reinstalled both. That didn't work, so I reinstalled the drivers through SysDVR's GUI. It spun for a while, then reported success and spat out the following log:

Installing Video interface: 0
Extracting driver files...
libwdi:info [extract_binaries] Successfully extracted driver files to 'usb_driver'
libwdi:info [wdi_prepare_driver] Successfully created 'usb_driver\usb_device.inf'
libwdi:info [wdi_prepare_driver] Creating and self-signing a .cat file...
libwdi:info [wdi_prepare_driver] Test signing is: Disabled
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\amd64\wdfcoinstaller01011.dll'
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\amd64\winusbcoinstaller2.dll'
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\usb_device.inf'
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\x86\wdfcoinstaller01011.dll'
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\x86\winusbcoinstaller2.dll'
libwdi:info [CreateCat] Successfully created file 'usb_driver\usb_device.cat'
libwdi:info [RemoveCertFromStore] Deleted existing certificate 'CN=USB\VID_057E&PID_3006&MI_00 (libwdi autogenerated)' from 'Root' store
libwdi:info [RemoveCertFromStore] Deleted existing certificate 'CN=USB\VID_057E&PID_3006&MI_00 (libwdi autogenerated)' from 'TrustedPublisher' store
libwdi:info [CreateSelfSignedCert] Created new self-signed certificate 'CN=USB\VID_057E&PID_3006&MI_00 (libwdi autogenerated)'
libwdi:info [SelfSignFile] Added certificate 'CN=USB\VID_057E&PID_3006&MI_00 (libwdi autogenerated)' to 'Root' and 'TrustedPublisher' stores
libwdi:info [SelfSignFile] Successfully signed file 'usb_driver\usb_device.cat'
libwdi:info [SelfSignFile] Successfully deleted private key
  Success
Installing driver(s)...
  USB\VID_057E&PID_3006&REV_0100&MI_00: Success
Installing Audio interface: 0
Extracting driver files...
libwdi:info [extract_binaries] Successfully extracted driver files to 'usb_driver'
libwdi:info [wdi_prepare_driver] Successfully created 'usb_driver\usb_device.inf'
libwdi:info [wdi_prepare_driver] Creating and self-signing a .cat file...
libwdi:info [wdi_prepare_driver] Test signing is: Disabled
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\amd64\wdfcoinstaller01011.dll'
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\amd64\winusbcoinstaller2.dll'
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\usb_device.inf'
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\x86\wdfcoinstaller01011.dll'
libwdi:info [ScanDirAndHash] added hash for 'I:\Nintendo Utilities\SysDVR\usb_driver\x86\winusbcoinstaller2.dll'
libwdi:info [CreateCat] Successfully created file 'usb_driver\usb_device.cat'
libwdi:info [RemoveCertFromStore] Deleted existing certificate 'CN=USB\VID_057E&PID_3006&MI_01 (libwdi autogenerated)' from 'Root' store
libwdi:info [RemoveCertFromStore] Deleted existing certificate 'CN=USB\VID_057E&PID_3006&MI_01 (libwdi autogenerated)' from 'TrustedPublisher' store
libwdi:info [CreateSelfSignedCert] Created new self-signed certificate 'CN=USB\VID_057E&PID_3006&MI_01 (libwdi autogenerated)'
libwdi:info [SelfSignFile] Added certificate 'CN=USB\VID_057E&PID_3006&MI_01 (libwdi autogenerated)' to 'Root' and 'TrustedPublisher' stores
libwdi:info [SelfSignFile] Successfully signed file 'usb_driver\usb_device.cat'
libwdi:info [SelfSignFile] Successfully deleted private key
  Success
Installing driver(s)...
  USB\VID_057E&PID_3006&REV_0100&MI_01: Success

But I'm still getting the same Timeout messages. The Troubleshooting guide recommends installing libusb-win but everything appears to have succumbed to link rot.

Regarding my network address, that just happened to be Asus' default and I didn't adjust it. I promise I'm on a personal network, though. No change here, either.

The only thing that I can think of that changed is the .NET SDK I have; is there a potential problem with 6.0.201? Is there a known-good version I can/should fall back to?

[exelix11]

Are you using a usb C to usb A cable ? Could you try with a different one ? Your USB instalò log seems fine so if the cable is not the issue i don't know if i can help you.

About network does pinging your console from you pc work?

.NET version shouldn't be a problem

[ToxiClay]

Yeah, I'm using a USB-A to USB-C cable. I've tried two different cables, and neither make sysDVR work. However, DBI works fine, so I know the console is able to communicate with the PC.

...Well. OK then; a different cable works flawlessly. Two different Anker-branded cables work for DBI but not for SysDVR, but a weird dumb no-name cable works for SysDVR.

Well I'm confused.

I can ping my console and log in to sys-ftpd, yessir, but the TCP Bridge mode is still not working.

On an unrelated note, even after I close a title, the configuration NRO claims that SysDVR is "already switching modes" and won't let me swap; I'm forced to reboot the console. What could be going on here?

[exelix11]

the switching modes warning is a limitation of the switch OS, sometimes the video capture process can get stuck until a game provides the next frame, when you try to switch modes but sysdvr is stuck it queues the request for the next time a game provides video data. When you open the settings and see the switching modes dialog it means your previous request is still pending (for one reason or another) usually entering a game that can be recorded fixes this.

I guess if you get that message every time it explains why network doesn't work, the network mode is never enabled.

BTW for incompatible games you can try dvr-patches

[ToxiClay]

When you open the settings and see the switching modes dialog it means your previous request is still pending (for one reason or another) usually entering a game that can be recorded fixes this.

Where does it put us if entering a game that can be recorded does not fix that, for the case of switching into TCP Bridge?

1. Console starts up, I wait a handful of seconds; SysDVR is in USB mode as it's set to be.
2. I start Atelier Sophie 2, and can stream to the SysDVR player in USB mode.
3. I jump back to the Home screen, enter the Album, enter the SysDVR configuration NRO.
4. I select TCP Bridge mode and select "Save and Exit."
5. I jump back into the game and let it sit, run around, open the menu.
6. SysDVR is stuck in the "switching modes" state, and won't shake itself loose without a reboot.

I don't even have to start a game for it to be stuck; switching modes immediately on startup is enough.

On a hunch, I deleted nx-ovlloader (sdmc:\atmosphere\contents\420000000007E51A) on the supposition that the presence of the overlay was interrupting the switching process somehow, but that doesn't seem to be the case; I'm still stuck.

However, as I suspected would be the case, setting TCP Bridge mode to be the default and rebooting did restore functionality. Even more curiously, I was able to switch modes from TCP bridge to USB and it worked fine, not getting hung up on changing. The other way around, USB => TCP Bridge, fails.

I don't suspect sysmodules could be the problem, but here are the ones I have remaining:

• 00FF0000A53BB665 (SysDVR);
• 00FF0000636C6BFF (Sys-clk);
• 420000000000000E (Sys-ftpd-light)

As a last resort, I backed up my entire CFW environment and then trashed it, going back to an absolutely minimal state: HOS 15.0.0, Atmosphere 1.4.0, Hekate 5.9.0, the latest SysDVR, a payload launcher NRO, and nothing more. Switching from the default RTSP mode to USB mode works and does not provoke the hang, but switching to TCP Bridge mode still causes the hang on "switching modes."

[exelix11]

As i said "switching modes" is a workaround for an os limitation so it's not an issue on its own. The problem is that it should finish quickly when you resume a game.

At some point there was a bug that would get stuck until a reboot but should be fixed by now, I'll be doing some tests to see if there's still something that can trigger it.

[ToxiClay]

As i said "switching modes" is a workaround for an os limitation so it's not an issue on its own.

On its own, maybe not, but recall that it only got stuck there when switching to TCP Bridge mode. Switching to either other mode works fine and doesn't get stuck. It's something specific to TCP Bridge mode, I think.

[exelix11]

I reworked the mode switching process, it is now independent of the system recording feature which should solve the problem. If you want to try it you can download beta versions of the client and the sysmodule from CI

[ToxiClay]

Alright, I just had the opportunity to try the beta version, and there's a bit of a larger problem.

The configuration NRO opens fine, and if I don't change anything, I can save and exit fine.

However, if I change modes and then save and exit and wait some time and then go back into the NRO, I'm greeted with the "Connecting to SysDVR" screen.

Buttons here are unresponsive, apart from the PWR button, which sleeps the system, and the Home button, which...

...gives me a blank screen.

Waiting on the blank screen eventually crashes with error code 2144-0001 (0x290).

What more information can I provide to help you narrow this down?

Here's Atmosphere's crash log, if it's useful:

01669251052_0100000000001000.log

[exelix11]

At this point I think there's an issue with your setup or console. Since capture is now completely independent this behavior means that the usb code gets stuck at some point but I have little control on that since its mostly libnx or system code.

[ToxiClay]

At this point I think there's an issue with your setup or console.

I'm genuinely baffled, though.

I won't pretend to know more about SysDVR than literally the person who built it, but...Switches are fungible, right? One instance of a given model is as good as any other, so why is mine fucking up when trying to switch modes if yours is working?

It works™ if I leave it on USB mode and just don't fuck with it, so at least I'm not dead in the water, but, like...I took the thing back to an absolutely bare-bones setup, and it still wasn't working. I'm incredibly confused.

[exelix11]

Unfortunately tech has a bunch of layers that build one on top of each other and stuff like this is hard to debug. Believe it or not just a few days ago I had an user on discord who couldn't get usb to work, turns out his usb Webcam was causing sysdvr client to crash.

You can try to change stuff like usb port and usb cable and see if that works. The behavior you see is caused by the usb deinitialization function getting stuck and that's a black box to me as well.

[ToxiClay]

Believe it or not just a few days ago I had an user on discord who couldn't get usb to work, turns out his usb Webcam was causing sysdvr client to crash.

Really? Damn, that's wild. I completely believe it; tech just sometimes does whatever the hell it wants to do, user intentions be damned.

Playing with it a little bit more, I believe you that it's somehow being caused by SysDVR or Atmosphere or something not "letting go" of the USB protocol when requested to. It will "pick up" the USB protocol and work fine, but it decides that It Has Had Enough™ of me when I ask it to put down the toy.

It doesn't matter if I have a USB cable attached or not; it just won't play ball. I wish there was a way I could help you diagnose it further, but I barely know enough to be dangerous.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.