Stuck at Loading 0.0 MBps when downloading webdav backup

[kevsestre]

Thanks for the recent update. It fixed the filenames of the uploaded saves for me. I can't download the backups though, both from Select(A Button) and Restore(Y button) when highlighting a webdav backup enty.

I'm using Nextcloud webdav.

[cubic3d]

Same here, stuck at downloading when trying to restore. Server is running Apache, but I have no access to the server logs. In the local log from JKSV I do only see the following after uploading a save game and trying to restore it from webdav:

WebDav: Create directory at https://<snip>/JKSV/
WebDav: Create directory at https://<snip>/JKSV/Enter%20the%20Gungeon/
WebDav: Response from WebDav. Parsing.
WebDav: Parsing response, using prefix: D:
WebDav: Response from WebDav. Parsing.
WebDav: Parsing response, using prefix: D:

Edit:
If downloading the save from webdav and confirming the overwrite of the local save, the resulting downloaded zip archive is empty (0 byte size). The uploaded file is not empty.

The handling seems also a little bit weird: The locally created savegame is named test. After uploading it's compressed and the naming changes to test.zip. If I try to download it and overwrite the local savegame, it creates a local empty archive test.zip which does not actually overwrite the source folder contents in test.

[UnderPsi]

Hello, I can confirm the same behaviour using synology webdav server: the name is now correct, but trying to restore a cloud save leads to system hanging indefinitely. I can press A which seems to download a zip save, but attempting to restore that save leads to "ZIP file is empty !" message
Edit: after seeing Impeeeza's comment on special characters, I tried again with very simple names (no "@" character for example). It seems to be behaving better, but in the end downloading a cloud save file results in an empty zip file locally. On server side, the zip file is not empty.

[impeeza]

I can confirm what on my Setup: WebDav using Apache Server on my Windows 11 workstation now I can see the full name of the backups and upload gamesaves having special characters on the name, but I can not download from the WebDav Server to the console to restore them. They got stuck at 0%.

@rado0x54, I don't know if worth fixing it now or wait for the full rewrite code.

[Nephiel]

Not sure if related but I am seeing this behavior right now and, according to the server logs, the origin path I set in webdav.json is appended twice on download requests.

• My webdav.json has "origin": "https://<snip>/jksv",
• Upload works fine and savefile ends up in https://[snip]/jksv/JKSV/gamename/savefile.zip
• Download gets stuck at 0%
• Server logs reveal the client is attempting to download https://[snip]/jksv/jksv/JKSV/gamename/savefile.zip which results in a 404 error.

edit: removing the /jksv path from origin in webdav.json and putting it (without any slashes) as the basepath instead, seemed to fix the download problem.

[impeeza]

Thanks for your input, with your post I tried my setup, I am using Apache on Windows and on the Access.log I see:

SwitchIP - impeeza [14/Sep/2024:17:25:51 -0500] "PROPFIND /Entrada/JKSV/Princess%20Peach%20%20Showtime%21/ HTTP/1.1" 207 2505
SwitchIP - impeeza [14/Sep/2024:17:26:07 -0500] "GET /Entrada/JKSV/Princess%20Peach%20%20Showtime!/Impeeza%20-%202024.07.27%20@%2015.26.19.zip HTTP/1.1" 200 -

so when the file is uploaded the file name is:
/Entrada/JKSV/Princess%20Peach%20%20Showtime%21/Impeeza%20-%202024.07.27%20%40%2015.26.19.zip

But when I press [Y] to restore the same file the Apache server is asked for /Entrada/JKSV/Princess%20Peach%20%20Showtime!/Impeeza%20-%202024.07.27%20@%2015.26.19.zip

(in my case /Entrada/ is the WebDav folder on the Apache server)

There are some differences, the ! and the @ do not get encoded on the GET statement, I don't know if that matters but could be the difference. doing some Wdav request from another windows machine using the later URL worked and the zip file is send OK.

for me the path never get duplicated folders

this is my webdav.json (100.100.100.100 is fake PC IP).

{
  "origin": "http://100.100.100.100",
  "basepath": "Entrada",
}

[kifujin]

Not sure if related but I am seeing this behavior right now and, according to the server logs, the origin path I set in webdav.json is appended twice on download requests.

• My webdav.json has "origin": "https://<snip>/jksv",
• Upload works fine and savefile ends up in https://[snip]/jksv/JKSV/gamename/savefile.zip
• Download gets stuck at 0%
• Server logs reveal the client is attempting to download https://[snip]/jksv/jksv/JKSV/gamename/savefile.zip which results in a 404 error.

edit: removing the /jksv path from origin in webdav.json and putting it (without any slashes) as the basepath instead, seemed to fix the download problem.

The "JKSV" is automatically appended to any path.

[Nephiel]

The "JKSV" is automatically appended to any path.

Yes, I meant the jksv in lowercase right before that.

[rado0x54]

There are some differences, the ! and the @ do not get encoded on the GET statement, I don't know if that matters but could be the difference. doing some Wdav request from another windows machine using the later URL worked and the zip file is send OK.

Thanks, that's very helpful analysis. That should help me to figure out the issue.

[J-D-K]

@rado0x54
Honestly, I'd prefer you just wait for the rewrite to do anymore work on WebDav if it's needed by then. I know it sucks for people having issues, but dude, I go back and look at a lot of this code now and wonder what I was thinking back then. I don't even understand how you managed to do it to be honest. I wrote the thing to begin with and have trouble navigating it now.

[lcy1364]

I've attempted to analyze the cause of this issue, and it appears to be related to the multi-threaded downloading process, which may result in an empty file. I've made some modifications to the code, but since I removed the original author's multi-threading functionality, I did not submit a pull request. Instead, I have uploaded a version I compiled. If you're experiencing this issue, you may try my modified version, and wait for rewrite version of @J-D-K

[lcy1364]

Should my actions have caused any inconvenience to the original author @J-D-K , please feel free to contact me, and I will remove it immediately.

[J-D-K]

I'm pretty hands off for this stuff. It's fine. I'm going to finish rewriting the remote storage with the rewrite and we'll see how it goes then. Before I threaded it and wrote directly to the SD, Google Drive was ungodly slow. That's why it's like that.

[lcy1364]

I was simply looking for a way to wirelessly sync my saves between my Switch and Switch Lite, but it seems quite difficult to find an effective solution. That is, until I came across your JKSV, which allows data synchronization via WebDAV. I have a Synology NAS that can provide high-speed WebDAV services, and it works very conveniently, even with single-threaded downloads, which remain quite fast. Unfortunately, it seems there is an issue with the WebDAV download functionality. As a result, I downloaded and analyzed the code. I sincerely appreciate the software you’ve developed and the work you’ve put into it—it’s truly excellent! @J-D-K