Releases: beallio/SDH-Ludusavi
Release list
v0.4.7 — A stopped sync is no longer a failed one
When you start a game, the plugin holds it for a moment and looks at your cloud save. If
that check stopped early, the plugin recorded a failure that was not one. This release
corrects that, shuts the plugin down cleanly when it reloads, and makes the diagnostic log
much shorter.
What changed for you
Resuming a game no longer leaves a permanent failure. If you pressed resume while the
plugin held your game, or the plugin released the hold itself after its safety timeout, the
save check stopped. That is correct behaviour. But the plugin then wrote a failed restore
into that game's history, kept it after a restart, and showed an error on the status strip.
It now records a skip and reads Restore skipped — cancelled before it finished. Your
saves are treated exactly as before. Only the report changed.
The plugin stops its background work when it stops. When the plugin reloads, updates, or
is turned off, its sync watchers and helper processes now stop with it. Before, some of them
kept running until you restarted the Deck. Refreshing the game list also no longer leaves an
abandoned save-tool process behind.
Quitting an untracked game does less work. If you quit a game that has no backup set up,
the plugin used to start a sync watch and three network checks, then throw the results away.
It no longer starts them.
The diagnostic log is far shorter and easier to read. About one line in seven carried no
information at all — one line per game every time the list refreshed, repeated messages about
the same update check, and lines that did not say which half of the plugin wrote them. If you
ever send a log for help, it is now readable.
Installing an update is quieter. The plugin used to write several identical notes to the
log during an install, and repeat the same background request each time. Both are fixed.
Known limits
The stopped-restore fix was checked on a Steam Deck far enough to confirm that no errors
appear in normal use. The exact case — pressing resume while a game is held — was not
reproduced on hardware before this release. It is covered by automated tests.
SDH-Ludusavi v0.4.7-dev.g351d86b (Dev)
SDH-Ludusavi v0.4.7-dev.g58e972d (Dev)
SDH-Ludusavi v0.4.7-dev.g5490a99 (Dev)
v0.4.6 — Autosync that gives up instead of hanging
Automatic sync runs at two moments you cannot avoid: the second you launch a game, and the
second you quit one. If the backup tool wedged at either of those moments, the plugin used
to wait it out for fifteen minutes — with your game frozen mid-launch for the whole of it.
This release puts a hard limit on that.
What changed for you
Nothing waits longer than three minutes. Every backup, restore, and save check now gives
up after three minutes and reports an ordinary failure. The old limit was fifteen minutes for
real operations and five for checks. Your saves are untouched by a give-up: the failure is
reported, the plugin releases its hold, and you can retry.
A wedged save command is stopped before your game continues. Previously the plugin could
let the game resume while an abandoned backup was still writing to your save files. It now
stops that work — and everything it spawned — and confirms it is gone before the game runs.
If it cannot confirm the stop, your game stays paused. This is deliberate, and it is the
one place where this release chooses a stuck launch over a fast one. A game writing to the
same files as a half-dead backup can destroy a save; a paused launch cannot. If you hit this,
the game will not start and you will need to reboot or force-quit it. It should be rare.
Overlapping work says so instead of vanishing. If a manual backup or restore is running
when you launch or quit a game, the two used to collide and the automatic one would quietly
skip. You now get UNABLE TO SYNC on the status strip, so you know your save was not
handled and can run it yourself.
Every save change at launch is protected by the pause. Restoring a newer backup was
already covered. Choosing "keep my local save" during a conflict prompt was not — that
decision now runs under the same pause your game is held by, so the game cannot start
reading saves while the answer is still being applied.
The status strip clears in three and a half minutes. It used to sit on screen for over
fifteen minutes after a stalled operation. Late failures still appear rather than being
swallowed.
The quick access menu opens faster. Its startup reads now happen together instead of one
after another, and it no longer keeps gathering information about the game you are on while
the menu is closed.
Measured on a Steam Deck
With three devices connected and a save already up to date, a launch was held for 3.5 seconds.
A launch that had to resolve a conflict and restore a backup was held for 17 seconds, and the
game started only after the restore finished. Quitting a game with changed saves took 19
seconds from exit to SYNCTHING COMPLETE. Nothing came close to the three-minute limit.
Worth knowing
- Syncthing's transfer-monitoring behavior is unchanged from v0.4.5.
- The three-minute limit has been proven by automated tests and by ordinary use on a Steam
Deck. Deliberately wedging a backup on real hardware has not been tested, so the give-up
path and the paused-launch fallback above are the least exercised parts of this release.
If you want to try them, use a game whose save you can afford to lose.
SDH-Ludusavi v0.4.6-dev.g7c285d6 (Dev)
SDH-Ludusavi v0.4.6-dev.g41e40df (Dev)
SDH-Ludusavi v0.4.6-dev.g1cc5592 — Safer autosync timeouts
This development build is for testing safer autosync failure handling before the next stable release.
What changed
- Backups, restores, and save checks now stop after three minutes instead of waiting much longer when Ludusavi is stuck.
- A stuck save command is stopped before the game is allowed to continue.
- Overlapping autosync work now produces a visible UNABLE TO SYNC result instead of silently disappearing.
- Every launch-time save change remains protected by the paused game launch, including choosing to keep the local save during a conflict.
- The running status strip clears after three and a half minutes, while late failures remain visible.
Suggested testing
- Launch a game whose backup is already current. The game should continue normally and show GAME SAVE UP TO DATE.
- Launch a game with a newer backup. Confirm the restore completes before the game resumes.
- Exit after changing a save. Confirm the backup completes and normal Syncthing status still follows.
- Start another Ludusavi action while autosync is checking. If they overlap too long, confirm you see one clear failure instead of an endless status or silent skip.
- Use a disposable test save for deliberate timeout testing. Never force a hang against your only copy of an important save.
Worth knowing
- Syncthing's transfer-monitoring limits are unchanged.
- If the plugin cannot prove that a stuck save command has stopped, it keeps the game paused to avoid simultaneous writes. This is intentionally safer than risking save corruption, but it may require manual recovery.
- Automated validation passed, but deliberate hangs and the rare failed-cleanup path still need real Steam Deck testing with disposable saves.
v0.4.5 — Games start without waiting on housekeeping
v0.4.5 — Games start without waiting on housekeeping
If you have more than one Steam Deck or PC syncing your saves, you may have noticed that
starting a game on a device you had not used for a while could leave you staring at a frozen
launch for the better part of a minute. This release fixes that.
What changed for you
Your game no longer waits for old backups to be tidied up. Before starting a game, the
plugin holds it briefly to make sure your latest save has finished arriving. That check was
also waiting for Syncthing to finish deleting old backup snapshots it no longer needs —
which has nothing to do with whether your save is there. On a device that had been switched
off for a while, that meant the game sat frozen while the only thing happening was cleanup.
One measured launch was held for 52 seconds without a single byte of save data being
transferred: the save had already arrived minutes earlier.
The plugin now waits only for the save itself. If your save is present, the game starts,
even while Syncthing is still clearing out old snapshots in the background.
The status strip stops claiming it is downloading when it is not. During that cleanup it
used to show SYNCTHING DOWNLOADING, which was simply untrue. It now stays quiet and then
reports SYNCTHING COMPLETE.
It still waits when it should. If your save really is missing or still coming down, the
game is still held until it arrives, and it now catches one case it previously missed —
where a file has been partly received but is not yet finished being written. Restoring a
half-arrived save would be far worse than a slow launch, so that check was strengthened
rather than relaxed.
If you turn on Debug Logging
The pre-game part of the plugin used to write nothing to the log at all, which made a slow
launch impossible to explain without inspecting Syncthing directly. It now records what it
is waiting for and why, each time that changes. Device names, file names, and folder paths
are never written to the log.
Security
One build-time dependency advisory was resolved by upgrading rather than by silencing it.
The fix was newer than this project's two-week quarantine on dependency updates, so it was
allowed through as a single pinned version; every other release of that package stays
quarantined and no advisory is ignored. This was never part of the plugin you install.