Homebrew RELEASE JKSV (save manager) for Switch

[impeeza]

OK. Zero shits given for double posting:

Fixing this new slow NS fetching thing is going to be a bit more involved than I thought. I'm still going over how to tackle it exactly. Normally all I save is the NACP from the control data. I now need to cache the icons too, which I don't save the JPEG data for. There was no reason to before. This creates a new problem: System titles don't have icons. I create them on the fly. I have no JPEG to save. That means encoding them to JPEGs to cache them... The other option is to grab the raw pixel data from the textures and save that instead. Each icon weighs in at 256KB then. That can add up quickly. Compressing that is an option, but that also impacts boot time...

I'm still working on it guys. That's all I'm saying. Never though I'd see the day where the Switch has me more stumped than the 3DS did...

`WOW, THANKS MATE!

 

[hippy dave]

Maybe it would be quicker to hack into nintendo's git servers and fix their bug?

 

[Deleted member 413168]

Maybe it would be quicker to hack into nintendo's git servers and fix their bug?

I'm still hoping for 20.0.2. Come on Nintendo, take mercy on us homebrew devs

Well, at least the side by side comparisons for reviewers will look better. Look at how much faster the switch 2 can load game icons compared the the switch 1!!!

 

[JK_]

I'm still hoping for 20.0.2. Come on Nintendo, take mercy on us homebrew devs

Well, at least the side by side comparisons for reviewers will look better. Look at how much faster the switch 2 can load game icons compared the the switch 1!!!

Not like we're going to actually get one, but I seriously would love an explanation for why now? It was fine the way it was for the past 20+ firmware versions... Anyone try running it through IDA or Ghidra and seeing what they changed?

Anyways. I'm considering a hybrid cache system. The control data for games is cached, but the system saves aren't. Rewrite already has a lot of the code done. I'll do some testing and then figure out how to implement the same system in the master branch without it collapsing and burning.

Since the size of the NsApplicationControlData is known, I can just save the count in the beginning of the file and load the entire thing into RAM and do it that way. Should make things a lot faster. I'll bypass nsGetApplicationControlData completely for system saves. It's gonna take a lot of restructuring, but it's gonna happen. I think the data section is going to need a complete overhaul in the master branch. The way the rewrite works is so different. I just pass pointers and references around to different application states in that. The master branch uses variables to keep track of everything and it's a major headache now.

 

[JK_]

Gonna start off by saying: I don't have a lot of stuff in my application records, but here's what I have from some basic timing and testing with the rewrite codebase and 20.0+:

• Initial, un-cached load takes about 10 to 12 seconds starting immediately after JKSV is launched from the homebrew menu.
• After cache is built, 2.5 seconds from when JKSV is launched from the homebrew menu.

I'll attach a build of the rewrite code below if anyone is willing or wants to give it a test run and post results to see how everyone else fairs with it. I wouldn't try to actually use it though. I'm still getting through figuring out exactly where I left off. I'm glad I wrote it better and documented everything a lot better though. It's making the process so much easier. If only other people did that...

 

[impeeza]

Gonna start off by saying: I don't have a lot of stuff in my application records, but here's what I have from some basic timing and testing with the rewrite codebase and 20.0+:

• Initial, un-cached load takes about 10 to 12 seconds starting immediately after JKSV is launched from the homebrew menu.
• After cache is built, 2.5 seconds from when JKSV is launched from the homebrew menu.

I'll attach a build of the rewrite code below if anyone is willing or wants to give it a test run and post results to see how everyone else fairs with it. I wouldn't try to actually use it though. I'm still getting through figuring out exactly where I left off. I'm glad I wrote it better and documented everything a lot better though. It's making the process so much easier. If only other people did that...

Thanks a lot mate for your great work, regards to the family.

 

[dsrules]

Gonna start off by saying: I don't have a lot of stuff in my application records, but here's what I have from some basic timing and testing with the rewrite codebase and 20.0+:

• Initial, un-cached load takes about 10 to 12 seconds starting immediately after JKSV is launched from the homebrew menu.
• After cache is built, 2.5 seconds from when JKSV is launched from the homebrew menu.

I'll attach a build of the rewrite code below if anyone is willing or wants to give it a test run and post results to see how everyone else fairs with it. I wouldn't try to actually use it though. I'm still getting through figuring out exactly where I left off. I'm glad I wrote it better and documented everything a lot better though. It's making the process so much easier. If only other people did that...

my test results
1st boot 68 seconds
2nd to 5th boot avg 10s with 6s being the fastest, 14s being the slowest

 

[JK_]

my test results
1st boot 68 seconds
2nd to 5th boot avg 10s with 6s being the fastest, 14s being the slowest

I've thought of another possible way to get the cached boot down even lower, well at least in theory it should. If I made the NsApplicationControlData member in the TitleInfo class a pointer, I could just basically transfer the pointer over from the cache read and skip the memcpy altogether. I don't think it would be that difficult to implement. I'm not sure how much time it's going to save really, but it's doable.

 

[froggy55]

Gonna start off by saying: I don't have a lot of stuff in my application records, but here's what I have from some basic timing and testing with the rewrite codebase and 20.0+:

• Initial, un-cached load takes about 10 to 12 seconds starting immediately after JKSV is launched from the homebrew menu.
• After cache is built, 2.5 seconds from when JKSV is launched from the homebrew menu.

I'll attach a build of the rewrite code below if anyone is willing or wants to give it a test run and post results to see how everyone else fairs with it. I wouldn't try to actually use it though. I'm still getting through figuring out exactly where I left off. I'm glad I wrote it better and documented everything a lot better though. It's making the process so much easier. If only other people did that...

hello i have tested this and for some reason it crashes everytime i go to back up a save so i am on fw 19.01 atmosphere 1.9.1 hekate 6.3.1 i launched using game overide and selecting in hb menu it launches i go to select a game i select new backup i then push the plus button to save then the app crashes to homescreen im not sure if i did something wrong but this is weird cuz with the previouse version i could save bckups but restorning would freeze my whole switch which is why i updated to this version anyways let me know if there is something i did wrong that i can fix otherwise maybe this still needs to be worked on thanks for the update though

 

[JK_]

hello i have tested this and for some reason it crashes everytime i go to back up a save so i am on fw 19.01 atmosphere 1.9.1 hekate 6.3.1 i launched using game overide and selecting in hb menu it launches i go to select a game i select new backup i then push the plus button to save then the app crashes to homescreen im not sure if i did something wrong but this is weird cuz with the previouse version i could save bckups but restorning would freeze my whole switch which is why i updated to this version anyways let me know if there is something i did wrong that i can fix otherwise maybe this still needs to be worked on thanks for the update though

I was already aware of this and tracked it down. Like I said, I wouldn't try to use it yet. It's really odd, actually. For some reason the TitleInfo instance/pointer I passed to the backup function was returning 0 as the application ID. This results in the function not being able to pull data it needs. It's at the top of the list to do when I have time today. The unzipping function has been kinda borked for a while. Same thing.

 

[billsue]

Gonna start off by saying: I don't have a lot of stuff in my application records, but here's what I have from some basic timing and testing with the rewrite codebase and 20.0+:

• Initial, un-cached load takes about 10 to 12 seconds starting immediately after JKSV is launched from the homebrew menu.
• After cache is built, 2.5 seconds from when JKSV is launched from the homebrew menu.

I'll attach a build of the rewrite code below if anyone is willing or wants to give it a test run and post results to see how everyone else fairs with it. I wouldn't try to actually use it though. I'm still getting through figuring out exactly where I left off. I'm glad I wrote it better and documented everything a lot better though. It's making the process so much easier. If only other people did that...

20.1.0 Unable to open

 

[JK_]

20.1.0 Unable to open

Does the log file say anything? It's located at sdmc:/switch/JKSV.log. Rewrite code is way better about logging important errors. At least, I hope it is.

 

[alcab]

I am in firmware 20.1.0 (so AMS 1.9.1). And I have to say I have a LOOOOT of content in my EMMC. And when I say a lot, I mean a lot, with 4 different users. I am also connected to my Google Drive account.

• Initial, un-cached load takes 4 minutes (aprox.) starting immediately after JKSV is launched from the homebrew menu.
• After cache is built, 12 seconds from when JKSV is launched from the homebrew menu.

Thanks a lot!

 

[JK_]

I am in firmware 20.1.0 (so AMS 1.9.1). And I have to say I have a LOOOOT of content in my EMMC. And when I say a lot, I mean a lot, with 4 different users. I am also connected to my Google Drive account.

• Initial, un-cached load takes 4 minutes (aprox.) starting immediately after JKSV is launched from the homebrew menu.
• After cache is built, 12 seconds from when JKSV is launched from the homebrew menu.

Thanks a lot!

Thank you. Priority now is getting basic functionality 100% complete in the rewrite code. Backing up and restoring. It was working great at one point, but I have a bad habit of making changes that break things. From there, porting over master branch code to modern C++ is what the goal is. Cache can be extended to cover as much as possible too. It'd be more work, but I could possibly cut system calls out completely for cached boots. At that point it's only creating icons that's the problem.

I'd thread the data fetching to show what's happening, but it would be a monster headache. I used SDL for graphics and it only allows the renderer to run in the main thread. Every texture must be created with it, in the main thread or they're just blank.

 

[Deleted member 413168]

Thank you. Priority now is getting basic functionality 100% complete in the rewrite code. Backing up and restoring. It was working great at one point, but I have a bad habit of making changes that break things. From there, porting over master branch code to modern C++ is what the goal is. Cache can be extended to cover as much as possible too. It'd be more work, but I could possibly cut system calls out completely for cached boots. At that point it's only creating icons that's the problem.

I'd thread the data fetching to show what's happening, but it would be a monster headache. I used SDL for graphics and it only allows the renderer to run in the main thread. Every texture must be created with it, in the main thread or they're just blank.

You can thread loading the icons by having a thread which waits on a uevent. When signaled, check if exit was requested. Otherwise, lock the mutex and store a copy of vector of jpg's (can be file name or jpg data). itterate through the array and load each jpeg. For each jpeg loaded, you lock another mutex for the result_data_array, then push the loaded data into and fire another uevent to signal to main thread that its loaded that icon.

I do something similar to this in my game menu (i async load the control data, but load the icons on the main thread but limit it to 2 per frame), you can find the code for it here:

the thread creation:
<https://github.com/ITotalJustice/sp...c6/sphaira/source/ui/menus/game_menu.cpp#L886>

the thread that does all the loading:
<https://github.com/ITotalJustice/sp...c6/sphaira/source/ui/menus/game_menu.cpp#L640>

polling on the main thread to check if theres any new data:
<https://github.com/ITotalJustice/sp...haira/source/ui/menus/game_menu.cpp#L930-L941>

Spoiler: this is how it looks (fw 20)

 

[froggy55]

I was already aware of this and tracked it down. Like I said, I wouldn't try to use it yet. It's really odd, actually. For some reason the TitleInfo instance/pointer I passed to the backup function was returning 0 as the application ID. This results in the function not being able to pull data it needs. It's at the top of the list to do when I have time today. The unzipping function has been kinda borked for a while. Same thing.

ok no worries i can wait for it to be fixed in the meantime i will use checkpoint its just i like the jksv for the bcat function some games require it like tetris 99

 

[billsue]

Does the log file say anything? It's located at sdmc:/switch/JKSV.log. Rewrite code is way better about logging important errors. At least, I hope it is.

The file shows

Error opening config for reading: Error opening file: 0x202.
No cache file found!

 

[Moe87]

20.1.0 Unable to open

If you see black screen at startup, so it is normal and you have to wait while, so full JKSV will be loaded, so after that, it load quickly, depends on various timing like members mentioned above, so better than wait more than one minute.

Post automatically merged: Jun 3, 2025

Oh wait, it looks like updated JKSV crashed when tried to backup two saves, even it run on full RAM (via game with hold on R).

There is error log - Error opening save data info reader: 0xBAEEE202.

Previous version of JKSV work fine, despite take over 1 minute to load.

 

[billsue]

thanks

 

[JK_]

Oh wait, it looks like updated JKSV crashed when tried to backup two saves, even it run on full RAM (via game with hold on R).

There is error log - Error opening save data info reader: 0xBAEEE202.

Previous version of JKSV work fine, despite take over 1 minute to load.

The crash has been addressed. I screwed up adding titles to the map. That was what was doing it. That error message is going to be in the log every time you run it too. It's because you can't open FsSaveDataSpaceId_ProperSystem.

The file shows

Error opening config for reading: Error opening file: 0x202.
No cache file found!

You might not be giving it enough time to really boot, like JeepX87 said. The old code would flip something to the screen quick to let you know it started. Rewrite code doesn't. I don't really consider stuff like that a high priority. I'm more concerned about other stuff. The only reason the rewrite even resembles the master branch at this point is because most of it was already done. I just made the code cleaner and used modern C++ instead of the nightmare that was the master branch.