Homebrew RELEASE JKSV (save manager) for Switch

[urherenow]

@impeeza ,but before OFW 16.0.0 it opened directly without that procedure,i also watched several videos on YouTube to understand the problem and if i had done something wrong.

Are you using any new sysmodules that you weren't using on FW 16? That error, when corrected by title takeover, is 99.9% likely to be a result of not enough available memory. Perhaps OFW 18 needs more ram than 16, so even without adding new sysmodules, the upgrade could have introduced the problem. How many sysmodules are you using? The only other similar report I've seen, has to do with google drive configuration. I am probably wrong here, but I think the google drive stuff makes use of the hidden browser applet, which needs a bunch more ram than a normal homebrew applet.

Again, using my own build (that likely has none of the re-write involved), I have no issues even in applet mode. The modules I have are: edizon, sysmodules, sys-clk, sys-patch (which won't matter because it self-terminates after it does its checks), and emuiibo.

 

[NeoGranzon]

Are you using any new sysmodules that you weren't using on FW 16? That error, when corrected by title takeover, is 99.9% likely to be a result of not enough available memory. Perhaps OFW 18 needs more ram than 16, so even without adding new sysmodules, the upgrade could have introduced the problem. How many sysmodules are you using? The only other similar report I've seen, has to do with google drive configuration. I am probably wrong here, but I think the google drive stuff makes use of the hidden browser applet, which needs a bunch more ram than a normal homebrew applet.

Again, using my own build (that likely has none of the re-write involved), I have no issues even in applet mode. The modules I have are: edizon, sysmodules, sys-clk, sys-patch (which won't matter because it self-terminates after it does its checks), and emuiibo.

@urherenow ,these are the modules i have installed on my Switch with OFW 18.0.0&AMS 1.7.0

 

[impeeza]

The solution is simple:

Always load HBL using FULL TITLE override, NEVER USE HBL ON APPLET MODE, no Homebrew give you support on applet mode.

Applet Mode is there for the very first setup of Homebrew, after that FULL TITLE OVERRIDE is needed.

also you can install a forwarder to launch HBL from HOS directly.

 

[urherenow]

@urherenow ,these are the modules i have installed on my Switch with OFW 18.0.0&AMS 1.7.0

I have never used this hekate toolbox thing so I can't really comment on it. I just look at the tesla menu to see what's there, and ovlSysmodules. If everything really is disabled/off when you get the crash, then I really don't know why you're getting that error. Sorry I can't help. Anything look different in /config/JKSV/JKSV.cfg?

#JKSV config.
workDir = "sdmc:/JKSV/"

includeDeviceSaves = false
autoBackup = true
autoName = false
overclock = false
holdToDelete = true
holdToRestore = true
holdToOverwrite = true
forceMount = true
accountSystemSaves = false
allowSystemSaveWrite = false
directFSCommands = false
exportToZIP = false
languageOverride = false
enableTrashBin = true
titleSortType = ALPHA
animationScale = 3.000000

 

[NeoGranzon]

I have never used this hekate toolbox thing so I can't really comment on it. I just look at the tesla menu to see what's there, and ovlSysmodules. If everything really is disabled/off when you get the crash, then I really don't know why you're getting that error. Sorry I can't help. Anything look different in /config/JKSV/JKSV.cfg?

#JKSV config.
workDir = "sdmc:/JKSV/"

includeDeviceSaves = false
autoBackup = true
autoName = false
overclock = false
holdToDelete = true
holdToRestore = true
holdToOverwrite = true
forceMount = true
accountSystemSaves = false
allowSystemSaveWrite = false
directFSCommands = false
exportToZIP = false
languageOverride = false
enableTrashBin = true
titleSortType = ALPHA
animationScale = 3.000000

@urherenow ,this is mine JKSV.cfg

 

[urherenow]

Looks like your version is definitely different than mine. After I backup my SD, I'll try using the latest from github and compare (and see if I can reproduce your problem). It's going to be a while though... currently 2+ hours left on my backup...

If I do reproduce it, I'll try to figure out how to get you the .nro that I'm using, assuming you trust me. I don't usually mod things, I just build them from source. Only mod I really have is my own fusee build with the kip patches re-enabled (which, in case you're wondering, shouldn't have any bearing on your issue). And my own updated lockpick_rcm.

 

[JK_]

Looks like your version is definitely different than mine. After I backup my SD, I'll try using the latest from github and compare (and see if I can reproduce your problem). It's going to be a while though... currently 2+ hours left on my backup...

The rewrite currently uses a slightly different config. I forgot about that too. @NeoGranzon should delete that because old JKSV won't know how to interpret the ints instead of bools.

 

[urherenow]

The rewrite currently uses a slightly different config. I forgot about that too. @NeoGranzon should delete that because old JKSV won't know how to interpret the ints instead of bools.

I just realized that myself. Just grabbed the latest release .nro and the crc32 matches mine (I may have had an issue building on my end... don't remember now). That config file might be the whole issue @NeoGranzon

EDIT: Nope. No issues at all building it. Don't know why I'm using that release at the moment, but at least it led me to the .cfg thing...

 

[NeoGranzon]

@JK_ @urherenow ,by editing the JKSV .cfg file (i have the latest version of Github),would you be able to make it work directly?

 

[urherenow]

@JK_ @urherenow ,by editing the JKSV .cfg file (i have the latest version of Github),would you be able to make it work directly?

I'd just delete it first. If it isn't there, it should create itself with all of the proper default settings. After all, when a new user goes to github, the .nro file is the only thing they put on their card to start with. Now I'm wondering myself, if I'm using the release instead of the last build I made, because my build was crashing like you, as a result of having the older config on my card. I honestly don't remember. And still 1.5 hours left on the backup I started. Huge SD cards are both a blessing and a curse...

 

[NeoGranzon]

I'd just delete it first. If it isn't there, it should create itself with all of the proper default settings. After all, when a new user goes to github, the .nro file is the only thing they put on their card to start with. Now I'm wondering myself, if I'm using the release instead of the last build I made, because my build was crashing like you, as a result of having the older config on my card. I honestly don't remember. And still 1.5 hours left on the backup I started. Huge SD cards are both a blessing and a curse...

@urherenow ,already tried this procedure with the latest version of Github and it still crashes.

 

[urherenow]

@urherenow ,already tried this procedure with the latest version of Github and it still crashes.

you don't have more than 1 jksv on your card, do you? Like /switch/jksv.nro, as well as /switch/jksv/jksv.nro? Because the github one is definitely the one I'm using, and I have no issues. One more time, does it still crash while opening hb with the title takeover?

Better yet, is your emummc RAW or file-based? If it's file based, make a fresh backup. Then format your card, and place ONLY your nintendo folder, emummc folder back, and /bootloader/hekate_ipl.ini back, then manually download and extract the latest hekate, Atmosphere, and jksv and add those. Nothing else. If at this point you get a crash, then the issue may be your SD card or your console's RAM. Also, before you boot out of hekate, make sure your cal0 is correct (as far as console serial# and what not).

 

[NeoGranzon]

you don't have more than 1 jksv on your card, do you? Like /switch/jksv.nro, as well as /switch/jksv/jksv.nro? Because the github one is definitely the one I'm using, and I have no issues. One more time, does it still crash while opening hb with the title takeover?

Better yet, is your emummc RAW or file-based? If it's file based, make a fresh backup. Then format your card, and place ONLY your nintendo folder, emummc folder back, and /bootloader/hekate_ipl.ini back, then manually download and extract the latest hekate, Atmosphere, and jksv and add those. Nothing else. If at this point you get a crash, then the issue may be your SD card or your console's RAM. Also, before you boot out of hekate, make sure your cal0 is correct (as far as console serial# and what not).

@urherenow ,no just one in switch/JKSV/JKSV.nro if i open it directly from HBmenu it crashes,however if i open it after starting a game by holding R pressed it doesn't crash and works normally.

 

[urherenow]

@urherenow ,no just one in switch/JKSV/JKSV.nro if i open it directly from HBmenu it crashes,however if i open it after starting a game by holding R pressed it doesn't crash and works normally.

All I can say is to do it that way then. I just tried a fresh build, which is 14 commits beyond the latest release, and it still works in applet mode, without messing with the .cfg file first. Except now, it just warns me that it's in applet mode, and that certain functions will not work, and the title up top, right next to "JKSV" says "APPLET MODE" in a bold red font. No crash. I wonder if you would crash running skyrim with hi-res mods... it's almost as if one of your ram chips are faulty.

Honestly, this thread is cluttered enough and it's time I get to sleep. Sorry I couldn't find a better answer for you.

Maybe see what the programs posted here do, for good measure: https://gbatemp.net/threads/ram-memory-test-utility-for-switch.630805/post-10125991

Two posts after that, someone said one of the tests passed, but the other test showed a stuck address, so use both.

 

[NeoGranzon]

All I can say is to do it that way then. I just tried a fresh build, which is 14 commits beyond the latest release, and it still works in applet mode, without messing with the .cfg file first. Except now, it just warns me that it's in applet mode, and that certain functions will not work, and the title up top, right next to "JKSV" says "APPLET MODE" in a bold red font. No crash. I wonder if you would crash running skyrim with hi-res mods... it's almost as if one of your ram chips are faulty.

Honestly, this thread is cluttered enough and it's time I get to sleep. Sorry I couldn't find a better answer for you.

Maybe see what the programs posted here do, for good measure: https://gbatemp.net/threads/ram-memory-test-utility-for-switch.630805/post-10125991

Two posts after that, someone said one of the tests passed, but the other test showed a stuck address, so use both.

@urherenow ,this also doesn't work in applet mode

i don't understand how you can get the apps to work directly.

 

[Hayato213]

@urherenow ,this also doesn't work in applet mode
View attachment 433086
i don't understand how you can get the apps to work directly.

Run it in full ram mode, either via title override or homebrew launcher nsp

 

[NeoGranzon]

Run it in full ram mode, either via title override or homebrew launcher nsp

@Hayato213 ,well in full ram mode by holding R i know how to make it work,he says it also works in applet mode.

 

[Hayato213]

@Hayato213 ,well in full ram mode by holding R i know how to make it work,he says it also works in applet mode.

Why not just use full ram mode.

 

[NeoGranzon]

Why not just use full ram mode.

@Hayato213 ,can i ask you a question:does the use of RAM increase based on the OFW&CFW updates?

 

[Hayato213]

@Hayato213 ,can i ask you a question:does the use of RAM increase based on the OFW&CFW updates?

No, system update might increase the internal storage space usage. In applet mode you don't have access to as much memory as full ram mode, so certain homebrew applications might not run well.