-
-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync savegames with SAF #552
Conversation
I would also like to add a folder inside the savegame folder, so that we seperate consoles. Is this a feature you'd like? |
If I'm not mistaken, this implementation only works with save files which are directly generated by Lemuroid, and not for ones which are generated by cores (such as PPSSPP, MelonDS, Citra and more). There, we basically have no control on how/when the files are accessed, that's why I still believe that a full double-sync between the two folder (or completing the work for Libretro VFS) is the only option in these cores. |
Ah now i see what you mean. This is only partially an issue, albeit this code needs adapting. While cores that use sram are fine, the others currently do not get updated as you stated. Though, they still get written to internal storage and can therefore be copied to saf. I just need to adapt the copy functions so that they can be called without the sram sync. This should lead to every core behaving roughly the same, saves are written to SAF when lemuroid calls either the 'exit'-game callback or onPause. I think this is the best possible without the callback-function i linked to in the other thread I will give it a try tomorrow |
I'd not put the full duplex sync in the onPause. The best option would be to have it in a WorkManager job so that it's not interrupted and the user would not be able to launch games while the save sync to external directory is in progress (we can potentially trigger this job whenever a game is closed like we do with the cache cleanup job). I'm available to discuss ideas if you want a quick check before diving into code in order to avoid implementations which can't be merged. |
It's not full duplex sync. Basically the internal storage is 'just' a temporary folder that doesn't get cleaned. Everytime a game is started, the corresponding savefile is copied from SAF to internal storage (if available), then the game can use it. When the game is closed, it gets copied from internal storage to SAF, overwriting what's there. (Except when the SAF-version is newer). It only 'syncs' on demand, only the game that is started, everything else is ignored This way we dont have to change the 'core'-mechanisms at all, they work the same as before.
I am not sure why onPause should not be used. Everything that happens there should not be visible to the user anyway, and saving is asynchronous anyway, isnt it? |
I have now separated the copy process from the sram usage. It can now copy arbitrary savegames before the game starts & after a game exits or pauses. It is currently only configured for gba&nds games, because i dont know which fileendings the other cores would use. This is however very easily added |
Closing in favor of #632 |
This allows the user to use arbitrary locations for savegames. It uses the internal folder as a "working directory", copying files from and to selected external storage if choosen. The file with the last modification timestamp ALWAYS wins this sync.
This can replace the custom google-drive implementation. It is always called when SRAM is saved. It only copies the current game.
Todo: