Homebrew RELEASE JKSV (save manager) for Switch

  • Thread starter Thread starter JK_
  • Start date Start date
  • Views Views 202,631
  • Replies Replies 633
  • Likes Likes 27
That's exactly how mine is though. I have three.
  • The first is a launch Switch that got banned shortly after I started JKSV. Not sure what triggered it.
  • The second was the one to replace that so I could play MHGU online with a buddy. It's also surprisingly RCM'able given when I bought it too.
  • Third is an OLED.
The first is the one with the battery issue. I've never had emummc. It was banned before that was even a thing. It gets warm in sleep mode and eats the battery in an hour or two at the most. Airplane mode solves it. I'm going to try what hippy_dave and Muxi were talking about earlier and leave it overnight to see what happens. The other two are fine. Really bizarre thing. Nintendo not addressing too is weird. This isn't just a CFW thing.
@JK_ i have some games that consume a lot of battery and make the Switch heat up,others that even if i play for over 2 hours do not go below 50%(Switch V1).
 
That's exactly how mine is though. I have three.
  • The first is a launch Switch that got banned shortly after I started JKSV. Not sure what triggered it.
  • The second was the one to replace that so I could play MHGU online with a buddy. It's also surprisingly RCM'able given when I bought it too.
  • Third is an OLED.
The first is the one with the battery issue. I've never had emummc. It was banned before that was even a thing. It gets warm in sleep mode and eats the battery in an hour or two at the most. Airplane mode solves it. I'm going to try what hippy_dave and Muxi were talking about earlier and leave it overnight to see what happens. The other two are fine. Really bizarre thing. Nintendo not addressing too is weird. This isn't just a CFW thing.
Last week I saw that again with an OLED. Had been modded fresh out of the box, sysNAND on 15.x, and never allowed to go online (so no linked accounts). It got the battery drain issue on emuNAND right after updating it to 20.x via Daybreak.
 
  • Like
Reactions: JK_
@Muxi i've never had any battery drain issues since i've had the Switch,perhaps because it's banned or because it's always
I only noticed this battery drain in standby mode with WLAN activated and this modified ‘system_settings.ini’ solved the problem for me. However, the problem does not exist or did not exist when flight mode is activated.
But this issue has nothing to do with this topic and has been discussed enough on the AMS Github.
 
I only noticed this battery drain in standby mode with WLAN activated and this modified ‘system_settings.ini’ solved the problem for me. However, the problem does not exist or did not exist when flight mode is activated.
But this issue has nothing to do with this topic and has been discussed enough on the AMS Github.
@Muxi i know what i wrote is off topic,i was just replying to a post.
 
@JK_ Seems at least using webdav with Koofr service, JKSV seemingly uploads the save data correctly and in the right space. It creates the appropriately named folder and drops the zip file in there. Inside JKSV I see the backup marked with WD.

That is, until I close the app and re-enter on the same Switch or a different Switch. Suddenly it won't see any of my webdav backups and whenever I try to make another backup, it fails to create a new folder. Instead it dumps the zip file inside the root folder causing the file structure to be completely broken.

Not sure what the problem could be, but just thought I'd give that feedback on your latest rewrite.
 
@JK_ Seems at least using webdav with Koofr service, JKSV seemingly uploads the save data correctly and in the right space. It creates the appropriately named folder and drops the zip file in there. Inside JKSV I see the backup marked with WD.

That is, until I close the app and re-enter on the same Switch or a different Switch. Suddenly it won't see any of my webdav backups and whenever I try to make another backup, it fails to create a new folder. Instead it dumps the zip file inside the root folder causing the file structure to be completely broken.

Not sure what the problem could be, but just thought I'd give that feedback on your latest rewrite.
So, the first upload works because everything on JKSV's side is local and a mirror of what is happening based upon response codes from the server.

What you're describing afterwards indicates JKSV is failing to get a listing at boot. It fails to create the folder because it already exists, but can't see it. When it constructs the URL, it's missing the parent ID, and it just uploads it to the root.

I'll see what's up with it later if I can.

@TheGioGrande
I think I got it. I'm running Apache and its responses always have a trailing '/' when dealing with directories. Forget that. I'm working on it now. It is really odd though. I'll get back to you once I have it figured out. It's really bizarre, actually.
 
Last edited by JK_,
  • Like
Reactions: impeeza
So, the first upload works because everything on JKSV's side is local and a mirror of what is happening based upon response codes from the server.

What you're describing afterwards indicates JKSV is failing to get a listing at boot. It fails to create the folder because it already exists, but can't see it. When it constructs the URL, it's missing the parent ID, and it just uploads it to the root.

I'll see what's up with it later if I can.

@TheGioGrande
I think I got it. I'm running Apache and its responses always have a trailing '/' when dealing with directories. Forget that. I'm working on it now. It is really odd though. I'll get back to you once I have it figured out. It's really bizarre, actually.

No worries! Massive props to you and what you've already done with the app. Just thought I'd provide some feedback to see if it was a bug or user error.

Looking forward to future releases!
 
@JK_ The solution to the battery drain problem is either to use a specially modified ‘system_settings.ini’ or to set up the system (emuMMC) again under FW 20.x.x. I can provide you with my customised ‘system_settings.ini’. Numerous users have successfully used it to solve this problem.
Thanks for this. I updated last night and I did notice the draining issue.
My set up is as follows:
Sysnand (online connected, nothing non legit installed. But I use jksv to restore and backup saves)
Emunand (offline, for all other stuff)

From what I understand this config will disable the persistent calls to Nintendo servers when offline, causing the switch to not go to sleep, but won’t it also affect sysnand, where I do use online?

I kinda need help on how I should set this up. Thanks
 
No worries! Massive props to you and what you've already done with the app. Just thought I'd provide some feedback to see if it was a bug or user error.

Looking forward to future releases!
Here's what I've found so far. Granted, I don't know how you have your webdav config setup. For this service you need the config like this for JKSV's code to work semi-correctly at the moment:
JSON:
{
    "origin": "https://app.koofr.net",
    "basepath": "dav/Koofr/JKSV",
    "username": "[email protected]",
    "password": "password123"
}

@TheGioGrande
Edit: I figured it out. I was right in the first post, but it went further than just the surface display names. I'll attach a build that I've confirmed works with Apache and Koofr. I also found a tiny oversight and fixed it. The latest fixed build is attached. Other than that it's just tweaks I made to certain things. It's getting closer now. I'm wondering if throwing it up on Git as a prerelease with a warning is the best idea? I would probably get more reports that way.
 

Attachments

Last edited by JK_,
@JK_: I tried your latest JKSV and tried using this save and got "Error processing save data meta!"
I can't see it without joining the group, but that probably just means it was created with old JKSV and rewrite JKSV couldn't find the meta in the save. It did restore it though, right?

I'll add another message so it doesn't look like an actual error. It's just backwards compatible.
 
I can't see it without joining the group, but that probably just means it was created with old JKSV and rewrite JKSV couldn't find the meta in the save. It did restore it though, right?

I'll add another message so it doesn't look like an actual error. It's just backwards compatible.
no it can't restore the save file. I think it doesnt work with 11/05/2024 version also.. it was posted 2022 :lol:

here's the save. thanks!
 

Attachments

@2K417
A lot of saves you find like that aren't actually formatted correctly for JKSV to use. Just drop this on your SD and it should be fine. I've actually noticed this myself. A lot of people take the backup folder and ZIP that instead of just enabling ZIP to begin with? What happens is there's an extra folder in the path. It's actually next to impossible to make JKSV detect it. There's no real way to determine what's extra and part of the path if you get what I'm getting at.

It did help me find another oversight to fix though.
 

Attachments

sorry i'm not familiar with this. there's no save files.. all empty.

here's the .log & .json
I'm assuming these errors are from trying to restore that ZIP I attached? I'm trying to reproduce it, but I can't:

Would you mind running a build with some extra path logging added in? A lot of the errors lead me to believe there's something wrong there.
 
  • Like
Reactions: Blythe93
@JK_: I was able to resolve the problem. Thanks!

problem: missing save files

solution:

- back-up all JKSV saves (to PC)
- deleted all JKSV related files
- copy the latest JKSV
- open switch > load JKSV > let JKSV generate new folder for the game/s
- copy the save files from your pc to the new JKSV generated folders.

(for future reference)

as a side note: JKSV is faster than before from over 1 minute load times to 10 secs.
 
@2K417
That's actually really interesting. I might investigate that. It's been a long time since I've used the master branch. I thought everything was more or less the same output path-wise except bypassing that lovely, incredibly well written, totally readable file in libnx called fs_dev.

Did you know that instead of just using strchr to locate the colon dividing the device and path, they made it decode every character one by one as UTF-8 to locate it? That made me laugh pretty hard. I'm like 99% sure that's really inefficient and a waste of processing time. As far as I know, UTF-8 was designed to not overlap and be backwards compatible with ASCII 100%. Just a little fun fact.
 
  • Like
Reactions: Blythe93 and 2K417

Site & Scene News

Popular threads in this forum