Emulator Issues #7621
closed
Saving in a game may not always function, even if OSD shows a successful write
0%
Description
With the way Dolphin currently flushes saves, it's possible that the written data may not actually make it to the disk. This can occur if Dolphin crashes before the buffer is flushed, or if a game needs to be terminated in an abnormal manner (i.e. due to excessive memory usage "breaking" things, such as from issue 7554).
I have been able to replicate this behaviour in a large number of titles, such as Paper Mario: The Thousand Year Door, Kirby 64: The Crystal Shards, and many games with autosave features.
This seems to most commonly (but not exclusively) occur when there are several saves in a short timespan.
To reproduce this, load up a game where you can easily see a difference between saves (i.e. being able to save in a different location), then save a few times, and try to save somewhere else that will be different than your initial save. Then, kill Dolphin's process, terminating it unexpectedly. You should find that you're at an older save that did flush successfully, or that no changes were saved at all.
Updated by Nick.Pelone about 10 years ago
I can confirm being able to reproduce this bug. It seems to have appeared around cc6db8cf26c1508ae382912bc25e64aaf12e0543,
"Merge pull request #939 from shuffle2/fix-memcard-flush2 …
shuffle2 authored 3 days ago
move the decision to delay raw memcard flushes out of the thread."
Updated by Nick.Pelone about 10 years ago
Additional note: reproduced using Paper Mario: The Thousand-Year Door.
Updated by JMC4789 about 10 years ago
- Status changed from New to Accepted
I just noticed this while messing around, this is a really big problem.
Updated by Anonymous about 10 years ago
- Status changed from Accepted to Won't fix
If dolphin crashes you always would have lost some data. That's the trade off for delaying writes to disk.
Updated by JMC4789 about 10 years ago
Is it only under crashes? If so, my mistake. I was having issues while testing PRs when I noticed memcards not updating, but it could be separate.
If Dolphin crashes, I dunno.
Updated by Anonymous about 10 years ago
fwiw I arbitrarily choose a delay of 15 seconds (from the last flush). This could be made quite a bit shorter (around 1 second or less, probably) without having any perf impact. So, that could be done. But generally, this is the same exact way it behaved before.
Also, memcard-folder doesn't have continuous writing at all (only when dolphin shuts down correctly), and you seem to be ok with this. The raw memcard constantly saving to disk is just a remnant of ye olden dolphin days when it would literally crash every 5 minutes in any game for no apparent reason. It's not like that anymore.
Updated by Anonymous about 10 years ago
Furthermore, if you see the OSD message, then it has flushed to disk. If you see the message and you apparently lost data, that means the game has written to the memcard since the last OSD msg.
Updated by pauldacheez about 10 years ago
I wouldn't design any part of Dolphin (or any other software, for that matter) to never expect to crash. I'm gonna send angry letters to my local Dolphin senator until they pass a bill to reduce that flush delay and implement continuous writing for memcard folders.
Updated by kodiacktech about 10 years ago
For what it's worth, I do think that a shorter flush delay may be ideal. Just my $0.02.
Updated by Nick.Pelone about 10 years ago
To be honest, I was experiencing this via adding Dolphin with a flag to autoexecute Paper Mario TTYD inside of Steam Big Picture. When I would want to exit the game, I would use Big Picture's close game, which may not send a nice signal to the controlled application to close cleanly. I guess that's how I was invoking the behavior. But I will second pauldacheez, I think some gracefulness should be considered in the way of writing data that doesn't go kaput in the event of a crash.
Updated by Nick.Pelone about 10 years ago
Lastly, I'll say that with a copy of dolphin built at commit 9b10d36a85bb27681f5d48e3ced9c142a1ac6b47 (the one before the commit referenced above) the issue is not present.
Updated by delroth about 10 years ago
- Status changed from Won't fix to Accepted
shuffle2: if we're not writing, could we at least make that apparent in the OSD?
If the OSD appears, I think it's fair that the user assumes the data has been written. Tying the OSD to actual writes would be better imo.
Updated by Anonymous about 10 years ago
- Status changed from Accepted to Fix pending
Updated by Anonymous about 10 years ago
- Status changed from Fix pending to Fixed