`backups` command hangs after doing a backup of one game only.

[tekert]

Hi, I'm having a problem where every time there is something to backup (save file was updated) a full system backup is triggered trashing all the hdds freezing the system up to 10min while is re hashes 15 plus years of save history.

This is a snippet from the extension logs when i do manual backup from playnite (when there is something new to backup), happens with any game, custom or default:

31-03 02:44:21.341|DEBUG|LudusaviPlaynite#LudusaviPlaynite:Running Ludusavi: find --api --path "G:\Data\ludusavi-backup" --backup -- "Return of the Obra Dinn"
31-03 02:44:22.849|DEBUG|LudusaviPlaynite#LudusaviPlaynite:Ludusavi exited with 0 and valid JSON content
31-03 02:44:22.849|DEBUG|LudusaviPlaynite#LudusaviPlaynite:Running Ludusavi: backup --force --merge --try-update --api --path "G:\Data\ludusavi-backup" -- "Return of the Obra Dinn"
31-03 02:44:24.384|DEBUG|LudusaviPlaynite#LudusaviPlaynite:Ludusavi exited with 0 and valid JSON content
31-03 02:44:24.384|DEBUG|LudusaviPlaynite#LudusaviPlaynite:Running Ludusavi: backups --api --path "G:\Data\ludusavi-backup"

In the first and second command the correct backup argument is sent to ludusavi, The third time is for a full system backup, i have to manually terminate the process to protect the system.

If i do it again (nothing updated in the saves), full system backup does not trigger.

31-03 02:54:06.728|DEBUG|LudusaviPlaynite#LudusaviPlaynite:Running Ludusavi: find --api --path "G:\Data\ludusavi-backup" --backup -- "Return of the Obra Dinn"
31-03 02:54:08.199|DEBUG|LudusaviPlaynite#LudusaviPlaynite:Ludusavi exited with 0 and valid JSON content
31-03 02:54:08.199|DEBUG|LudusaviPlaynite#LudusaviPlaynite:Running Ludusavi: backup --force --merge --try-update --api --path "G:\Data\ludusavi-backup" -- "Return of the Obra Dinn"
31-03 02:54:09.962|DEBUG|LudusaviPlaynite#LudusaviPlaynite:Ludusavi exited with 0 and valid JSON content

Using the latest version of the extension with ludusavi 0.16

[mtkennerly]

The third time is for a full system backup, i have to manually terminate the process to protect the system.

The third command is backups, not backup. The backups command returns a list of all your existing backups, but doesn't create any new ones. It does this by reading the mapping.yaml files from the backup directory (one per game).

The plugin also runs the backups command on startup, so I'm not sure why it would only have a problem specifically after making a new backup. Some questions for you:

• Is G: Google Drive (or any other special type of drive)?
• How much disk space does G:\Data\ludusavi-backup take?
• How many games are backed up?

[tekert]

Hi, oh you are right, didn't notice, the thing is that command alone is what causes a rehash of every original mapping inside G:\Data\ludusavi-backup

• G: is a normal 6TB HDD drive, the folder ludusavi-backup is currently hooked to sync with MEGA
• 3.4GB
• 377 games, some of wich are from old drives not connected anymore, and some where meant as a one time only backup from old backup folders.

edit: I now see the problem, when manually running backups --api --path "G:\Data\ludusavi-backup" around game >200 it starts rehashing old drives mixed with the new ones causing unnesesary disk activity, In windows resource monitor i see it read the content of every single old save for no reason.

For clarification, When doing backups --api --path "G:\Data\ludusavi-backup" Every file content inside the C(Fast), E (slow), F (medium), G(Fast), I(Fast) is read again, when it scans the E drive along with the F drive, at the same time some G scanning is intermixed, the sound of the hdd trashing is scary, not to mention the time is takes, close to 8min every single time a backup is done.

[mtkennerly]

You're absolutely right; the backups command is needlessly doing a full restoration preview. This was an oversight on my part after a series of changes:

• Originally, a restoration preview was very cheap because it was strictly based on the mapping.yaml content.
• When I added the backups command, I reused the restoration preview code to get the list of available backups.
• I added the change detection code (for new/updated saves), which made restoration previews more costly.
• I didn't think to revise the backups command (it's much faster on my system, so I didn't notice any symptoms).

On my system (367 games, 3.14 GB, only drive is an SSD), fixing this drops the backups execution time from 2.949s to 1.474s.

Here's a 64-bit preview build with the issue fixed. You can also check the other changes since 0.16.0, which are included in this build as well: ludusavi-v0.16.0-post.38+65c8e98-win64.zip . Please let me know how it performs for you with the fix.

[tekert]

That was fast fix, yes i was using the latest commit before to check if this was fixed there :blush:

Tested commit 65c8e98, All fixed, tested from playnite and with a direct command on the terminal.

Thanks, any help i can provide just pm me. We can close this if everything is done :+1:

[mtkennerly]

Glad to hear it! Thanks for testing it out :)