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.