arkos
arkos copied to clipboard
christianhaitian
Feature request: save configuration files and saved games in cloud
Hi. I don't know if this is the right section to post this. but I can think of a new functionality that I don't think is very difficult to implement. It is to have in the menu an option to configure a Google Drive account that allows synchronizing the retroarch configuration folders and the saved games of the emulators. This would be necessary in case this information is lost when resetting the console or it breaks. Also if there is a problem in any update and the data is lost. Surely the experts can think of more profits. Greetings and very good job.
I have thought of trying to configure something like this more so for the retroarch configuration folders. Not sure how soon I can review to see how I can bring this feature to the platform but I will definitely consider this as I agree with your thoughts on this.
agree. if you need help to do this.I can do research on cloud services, even prepare a bash script for arm64 that installs and configures it. Please let me know if you need help.
As an intermediate solution to this, today's updates includes a Backup Settings and Restore Settings ability in the options/Advanced section. These will backup and restore the following settings to roms/backup/arkosbackup.tar.gz:
Amiberry savestates and whdboot configuration and save Current Timezone Drastic emulator configuration Emulationstation collections Emulationstation settings Mupen64plus standalone emulator gamepad configuration Retroarch configurations for both 64 bit and 32 bit Retroarch cheats for both 64 bit and 32 bit Retroarch overlays for both 64 bit and 32 bit Wireless connections
As the compressed file will contain sensitive information such as wireless ssid passwords, it should be stored securely off the sd card once created if there's a concern of possible prying eyes.
Looks like rclone might be a good solution. You could have the user store their credentials using that onscreen keyboard tool u already have implemented, and then link to a script from /etc/network/if-up.d/? (or maybe crontab would be more appropriate)
After looking around at a few options, I can't find anything that seems like it would be a good user-friendly solution for non-technical users. At best, the user would still have to create an API key on whatever cloud service, and then type it in using the msgbox keyboard which definitely isn't ideal for something like a 32 character alphanumeric key, for example. (btw, @christianhaitian, is the msgbox command you use in all the scripts a custom executable? Since it's so generically named, I haven't been able to Google anything about it.)
It is a custom executable that was designed for the OGA specifically. Unfortunately, no source code is available for it.
@christianhaitian Understood! Same with osk for the onscreen keyboard? Is there documentation for either?
Good news, I have a working proof of concept for Dropbox! I'll write the scripts and open a PR soon. Expect to see it in a week or so.
That would be great! I'd love a poc that I can hopefully expand to drive if possible. If not, dropbox is better than nothing on this for now.
Just wanted to chime in my support for a way to cloud host and retrieve save files. Would love to seamlessly be able to play on different devices.
The implementation would require wifi at runtime and any saving intervals, which would impact battery life a good deal 🤔 so maybe my dream won’t be a reality just yet.
But backing up to the cloud ad-hoc would also be great :)
@travisvn See my arklone repo if you would like to try out the feature waiting to be merged in #126.
I've been thinking about implementing a little something for myself:
- Detect / Add multiple devices (I have a RG351M and ordered a RGB10 Max)
- Poll save states over ssh / detect most recent changes
- Push more recent save states on the other devices; to be able to switch devices and continue seamlessly
- Sync a roms collection from a folder on the computer to the devices
Or is there already a tool that does it?
arklone may come close to that when ready but is geared towards cloud saving
Yes, I have something a bit different in mind.
I'd rather sync to the computer, to avoid all the configuration boilerplate. Users would be free to sync their computer folder to their Dropbox. It's actually the way I use Calibre for ebooks: my Calibre library folder is in my Dropbox folder, therefore any change I do in Caliber (e.g. metadata of a book, new book, etc.) is synced automatically. Caliber isn't directly integrated to Dropbox, and doesn't need to be.
My understanding is that arklone wouldn't automatically sync the save states between multiple devices; user would have to create backup on one device and restore on the next one, for all games in bulk. Am I wrong about this?
Also, I'd do something more light-weight and user-friendly, and that would not require any change to ArkOS.
I think I'll write my own little scripts, and check whether I can make something re-usable for non-tech-savvy users.
I think I'll write my own little scripts, and check whether I can make something re-usable for non-tech-savvy users.
That's how my whole journey started, lol.
I'd rather sync to the computer, to avoid all the configuration boilerplate.
Arklone will also work with local remotes, you just need to set them up in your rclone config.
My understanding is that arklone wouldn't automatically sync the save states between multiple devices; user would have to create backup on one device and restore on the next one, for all games in bulk. Am I wrong about this?
As long as your retroarch.cfg save settings are the same on each ArkOS/Ubuntu/Debian device, Arklone should automatically sync saves to/from the chosen remote in the background, without user intervention. (However, there's a bug I'm working on this week that potentially causes data loss when using multiple devices.)
All right, it seems promising.
- Is it planned to also manage roms collections?
- Could it be synced with Retroarch running on desktop computers as well? I suppose rclone can be configured for those too?
- To run arklone on other device OS, would you need to make a PR to each of them? Or if not integrated to the OS, install it in each device? Would you have to write a different installation script if device OS isn't Debian-based?
* Is it planned to also manage roms collections?
Not at the moment, but it’s probably not difficult to add in one way or another.
* Could it be synced with Retroarch running on desktop computers as well? I suppose rclone can be configured for those too?
Yes, it should work on any Debian install. I initially wrote and tested this on my Laptop, running Lubuntu. If I was smart when I wrote this months ago, there shouldn’t be anything ArkOS-specific in the Arklone repo, except for a couple paths specified in config.sh
The main reason this project exists is because I use Dropbox, and there’s no Dropbox Linux client. On Windows or MacOS, there’s really no need for either Arklone (or rclone), because you could just use the official client to manage your save directories.
* To run arklone on other device OS, would you need to make a PR to each of them?...
Not sure what you mean here, but you mentioned “pushing” updates to other devices in the last post. At the moment, Arklone only pushes to one remote at a time. I like this because it means the one remote is always the de facto archive. If you start adding in other remotes to the equation, (which could be local to your machine, LAN, or in the cloud), questions are raised like; which is the canonical copy, what happens when two remotes are out-of-sync (like if one is not connected or powered up when you “push” from downstream), etc.
Or if not integrated to the OS, install it in each device?
Yes, it needs to be installed to each device running ArkOS.
Would you have to write a different installation script if device OS isn't Debian-based?
Theoretically, running the bash scripts manually should work on MacOS. Otherwise, Arklone relies on systemd for all the path watching and script execution, and apt to install rclone.
On Sep 10, 2021, at 5:30 AM, benckx @.***> wrote:
All right, it seems promising.
Is it planned to also manage roms collections? Could it be synced with Retroarch running on desktop computers as well? I suppose rclone can be configured for those too? To run arklone on other device OS, would you need to make a PR to each of them? Or if not integrated to the OS, install it in each device? Would you have to write a different installation script if device OS isn't Debian-based? — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/christianhaitian/arkos/issues/37#issuecomment-916767402, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV5H47ZTULBIU2XFMZSZN3UBHF2DANCNFSM4UFZ33TQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I agree that writing sync logic wouldn't be trivial. Even Steam doesn't always get it right. It might also trigger cascade behavior where the most recently copied file is now considered the more recent (as it has a later timestamp than the source file) and would be flagged to be pushed where it was copied from, etc. It has to be designed carefully and unit tested.
I have started working on an app to manage ROMs and save files: https://github.com/benckx/vaporwave
Nice. I'm almost at the finish line with the arklone bug fix/update. I was intrigued by your idea of unit testing, it hadn't occurred to me to write them for this app, but it does seem pretty important since we're writing to/from the filesystem. I've pretty much rewritten the entire app to accommodate for it (and also make it more friendly for other devs to extend) and am now just bug-hunting and need to do a documentation pass. Follow #126 for updates, it should be ready for testing within a week or so.
Indeed. For comparison of save files, command result parsing, etc. it's something that will improve overall quality and avoid regressions. However a lot of cases are still missing. It's certainly not the most fun thing to write.
I would focus on the next few weeks on improving save files comparison (sometimes only the srm file has been updated and no save state has been created, which might mess up the current algorithm; also PPSSPP is not compatible at the moment) and on UI / UX (file transfer progress bars, async refreshes, etc.)
@benckx Thanks for the PPSSPP tip. I forgot ArkOS uses the native app and not RetroArch/lr-ppsspp and neglected to address that months ago.
It's been awhile since we've had anymore movement on this. Not sure if this is still being worked on. If it is, I will reopen this request.
I'm not actively working on this at the moment, no. I just made a small prototype. There's still quite a lot I'd like to add in the future. https://github.com/benckx/vaporwave
Hi everyone, I hope you are all doing well.
Arklone has a lot of technical debt and could probably benefit from a total rewrite (maybe in Python instead of Bash/systemd since it's no longer considered for a merge into RetroPie), plus there's the outstanding exFAT issue that I never followed up on after the new driver went into ArkOS. (I still only have an RG351P)
That said, Arklone-ArkOS and Arklone-RetroPie both work as intended well enough and I haven't had a reason to update them. Based on forum posts and GitHub stars, I think there might be up to a few dozen users between versions, and no one's experienced any serious issues that I'm aware of.
Anyway, I'd say leave the issue closed since unfortunately, it seems like it's pretty non-trivial to deliver a multi-platform solution that's both feature-robust and user-friendly to configure for Linux noobs (which seems to be the vast majority of end-users of supported devices).