search

v1993 / nxdumpclient

A client program for dumping over USB with nxdumptool
GNU General Public License v3.0
17 stars 1 forks source link

[BUG] Dumping romFS causes desktop lag and potentially crash #20

Open PolyCatDev opened 6 months ago

PolyCatDev commented 6 months ago

The issue

When I dump a large game such as TOTK over nxDumpClient my desktop lags horribly and eventually crashes. I tried with BOTW in the past and that only lagged out my PC.

Steps to reproduce

  1. Connect switch to PC
  2. Dump the romFS of a game

What do I use

I use the flatpak from flathub and Fedora Linux Silverblue 40 with Gnome 46.1

v1993 commented 6 months ago

Since I don't have TotK personally to test - can you observe memory usage increasing before crash? If so, can you confirm that it is nxdumpclient process that consumes memory?

PolyCatDev commented 6 months ago

Ok. The problem seems to come form over-stressing the CPU. My memory is just fine but the CPU has a huge spike. Screenshot from 2024-05-05 22-57-37 Also here's a video: https://files.catbox.moe/dsg9nz.webm

PolyCatDev commented 6 months ago

I'm guessing this is happening because of the very rapid movement of the loading bar because the official py script works just fine.

v1993 commented 4 months ago

I've been able to reproduce abnormally high CPU usage with dumping Fire Emblem Engage, which also has a lot of small files, although it's worth noting that only one CPU core is stressed and it's generally not that high of a load (15-20% in my test). Also, weirdly enough, the problem actually gets worse if nxdumpclient is ran in background: CPU usage increases and xdg desktop portal process starts eating CPU as well.

While I can't promise a concrete release date, this will definitely be much easier to fix with a reproduction on my end once I get to it.

v1993 commented 2 months ago

I was pretty sure I've posted this before, but apparently I never got to it...

Either way - the problem is primarily caused by very rapidly creating and destroying session inhibitors (at the beginning and at the end of each file transfer), which involves communicating over D-Bus with desktop services. The proper fix is to implement mass transfer control commands added in ABI 1.2 (which will also incidentally make progress bar move more slowly), which will allow to only create/destroy inhibitors at the beginning/end of the whole mass dump process.

As such, this is mostly a duplicate of #18, but I'm keeping this open in case changes in question will turn out to be insufficient.