Retroarch: Fix your battery backup system this is ridiculous.

[mlfarrell]

Taking a few minutes to calm down, I’m furious. This program managed to crash itself and lose 2 hours worth of game saves I assumed were sync’ed to the disk. This is not a good emulator. It’s basic common sense to synchronize to the disk at least every half hour. Preferably every 10 minutes. That will not affect performance at all for the player. This should be ON BY DEFAULT!!

Hell, if you’re really that worried about performance, just attach a hook to any code that writes to the battery backup and compare a hash/checksum with a known value and write to the freaking HARD DRIVE if it’s changed. Again, commonsense.

If you don’t want angry messages like this from users, then exercise basic common sense. I understand you made this program for free, but I don’t appreciate having over two hours of my time wasted because I assumed that damn program was saving my work.

This is not a good emulator

[RobLoach]

I hear three things from this...

1. You're upset that you lost two hours of gameplay.
2. It crashed... Mind sending over the log file and letting us know which operating system/device you're on so that we can help you in figuring out why it crashed?
3. Requesting that RetroArch autosaves every 10 minutes.

[mlfarrell]

The app crashed when cycling through the shader settings. I don’t have time to send you a log.

fr500, You will never get me to agree that your reason to not save the data after running for two hours is “perfectly valid”. I have an SSD, most modern computers do not have a problem with thrashing when you are dumping mere megabytes to the disk. Operating systems typically will have write buffers that aren’t even flush to the disk until needed. This isn’t 1995. The ignorance is on your part.

[fda77]

Automatic save enabled would be nice, beside the option is hidden behind "advanced" switch and was not visible for me a long time. But the options should not be seconds, i think minutes should be good

[mlfarrell]

Thx fda77. 10 minutes seems to be about right. Sorry for being a jerk. I just can't stand the idea of loss of massive progress being even possible. I've authored a VR editor "tool" program that has to maintain 90 FPS at all times and spawning a BG thread to save the user's work every 10 minutes doesn't affect the performance of the app for the user whatsoever. I don't think it should be an issue here considering the SNES battery backup RAM can't be all that large.

[hizzlekizzle]

spawning a BG thread to save the user's work every 10 minutes doesn't affect the performance of the app for the user whatsoever

We support a lot of platforms, and a number of them don't support threads. Some of them have absurdly crummy I/O performance, as well.

I don't think it should be an issue here considering the SNES battery backup RAM can't be all that large

That's true, but N64 states are >5MB and PPSSPP's states are >90MB.

So, we have a bunch of platforms where it's not good for any core, some where it's not good for all cores and the rest have no way of communicating whether it would be okay (i.e., a fast, modern machine like yours) or not (i.e., an old PC being repurposed for retro gaming). That's why it's not on by default.

[markwkidd]

I've installed Lakka/RetroArch onto some pretty low power systems, none of which have a problem writing a PPSSPP state to disk with my standard settings of 10 seconds for autosave

If there are platforms, maybe the consoles, which couldn't have this enabled by default, that could be handled with a define and have it set to off by default. There are a lot of features with different defaults based on platform, it's not hard to do that.

For that matter, many of the default RetroArch settings are actually not good for low power as-is. The default GUI settings in Lakka make it almost unusable on S905X systems, for example, which are officially supported even! We live with it because the default settings are good for the majority of users

Someone did the math on SSD wear in a previous issue about this, and made a convincing argument that even if the default auto save interval were 10 seconds, it would take more than the average lifetime of a PC before the wear would be a factor. That is why I now set my autosave interval to 10 seconds, except when I frustratingly forget and then loose something like the OP

[twinaphex]

We cannot set it on by default. When we last tried to set it on by default, we immediately got complaints that certain games were broken as a result due to how they used SRAM as RAM/scratchpad. The Shiren The Wanderer games are a perfect example of that, where it writes to SRAM with every step you take (that is every D-pad press you do).

Simply put, stop raging and just turn the autosave interval to 10 seconds or whatever suits your fancy. While we cannot do anything about the loss of progress, really it is not our fault either. Whenever there is a crash, it is usually the core crashing and not RetroArch. There are unreasonable expectations here where a core is a completely different program and therefore subject to its own crashes and bugs, and so is RetroArch.

None of this has anything to do with RetroArch. We need to support save states and save RAM agnostically across cores. This whole thing from the OP 'considering the SNES battery backup RAM can't be all that large.' basically shows why he cannot be a maintainer of the RetroArch/Libretro project, because he cannot see that RetroArch has nothing at all to do with the SNES, neither are we going to treat some cores differently from others and then base an auto save interval strategy around that.

Simply respect that RetroArch is not what you want it to be. We already provide hundreds of thousands of convenience functionality requested by users that frankly was not our initial design goal/brief of RetroArch, which was to be a LIGHTWEIGHT, reference frontend for the libretro API. It has now turned into something that tries to meet user expectations of what they want RetroArch to be, but honestly, some things is where a clear line in the sand needs to be drawn and 'here but no further'. Spare us all the outrage and just change one setting to whatever you want it to do, and don't immediately go into histrionics like 'this is not a good emulator'. You are correct, it is not an emulator and it never will be. Thank God there is more to this project than just that.

Frankly, if this conversation keeps bordering on the vitriolic, I might start entertaining just closing it. I also would appreciate it if we don't start changing the goalposts here and getting into all sorts of wild tangents as to other pet peeves people have with RetroArch. One issue at a time here please.

[mlfarrell]

Well... I strongly disagree. But it’s your project, not mine. At the very very least you should make this super clear to anyone using the emulator. If I had known your design goals / architecture was the above, I would have never bothered to use this software.

[twinaphex]

Frankly, you should check your abrasive attitude at the door. Had you done that from the beginning, you likely would have received a different response.

There is nothing, absolutely nothing, that gives you the right to respond to us in such an abrasive manner. Also, you keep talking about ‘your emulator’. RetroArch is not an emulator. Already told you that before.

[twinaphex]

Better yet, if you can do it so much better, instead of whining, do something about it. If everybody acted like you whenever they encountered something they did not like, the entire purpose of this project being open source would be nil and void.

Also, telling somebody ‘I do not have time to send you a log’ yet you have all the time in the world to rant angrily for paragraphs on end. It is simply not a collaborative and nice attitude you are portraying. Dont expect any further support then. We are not your whipping boys. Treat us with respect and you will get respect back in return.