Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Sstate Corruption Fix?
#1
Hi,
I recently downloaded pcsx2 and started playing my Persona 4 on it. Everything was going smoothly but one day while I was playing, the current at my house went out and once it returned, the sstate I was playing on doesn't work anymore.

A message pops out saying:

Data read failed: Invalid or corrupted gzip archive.
Path: C:\users\I-an\Documents\PCSX2\sstates\DEDC3B71.000

and this is what's on the log:

(pxActionEvent) Data read failed: Invalid or corrupted gzip archive.(VM_UnzipFromDisk)
File/Object: C:\Users\I-an\Documents\PCSX2\sstates\DEDC3B71.000

My other sstates work but I spent 3 hours grinding ><
Is there a way to fix this or am I screwed? :x
Reply

Sponsored links

#2
Doubt you can do much to fix it, just activate "Backup before save" under the System menu in PCSX2 0.9.8 so you have a more recent savestate to go back to next time.
Core i5 3570k -- Geforce GTX 670  --  Windows 7 x64
Reply
#3
Aw man, thanks anyway! I should have thought about backing up the saves.
Reply
#4
It's sadly the nature of save states... They were never designed to completely replace memory card saves.
Reply
#5
they should be a bit safer than that though ;p

corrupt state signifies corrupt data in memory prior to the save though, this could be an emulator glitch
Reply
#6
(05-05-2011, 08:25 AM)Squall Leonhart Wrote: they should be a bit safer than that though ;p

corrupt state signifies corrupt data in memory prior to the save though, this could be an emulator glitch
It could, but it's more likely a result of the abrupt power down. Anyway, as ShadowLady noted, enable "Backup before save" and if it gets corrupted again, just load the backup (previous save state) instead (System -> Load State -> Backup - will load the backup of the last accessed slot).
[i7-3630qm/gt650m-2G/Win-7] [i7-4500u/R.HD8850m/Win-8.1] [2010-MBA/OSX-10.9.x]. Scroll smoothly with SmoothWheel for Firefox.
Reply
#7
that kind of points to the file not being closed properly after performing the write though.

the op never said that he was in the process of saving when the power cut out, so if the handle on the file is not being closed when the write completes, then that would explain why it corrupted with the power cut.

OP, when was the last time you saved prior to the power cut, it shouldn't take more than 15-20 seconds packing the memory state and writing to the drive (including cached write).
Reply
#8
(05-05-2011, 09:27 AM)Squall Leonhart Wrote: that kind of points to the file not being closed properly after performing the write though.

This actually sounds about right. I've had similar problems with the .ini files being corrupted on a power shutdown (these ones should definitely have been closed after just moments after a write Tongue2), but only PCSX2 inis, plugins are always fine.
Core i5 3570k -- Geforce GTX 670  --  Windows 7 x64
Reply
#9
It's a bit unfair to say it should be more secure than the memory content it saves... ideas how to enhance the sstate mechanics are welcome...

To be true to my own words a suggestion then: Option to automatically cycle the already existent slots, if possible with a thumbnail. Option to automatic timed sstate (oh yes, I'm prone to forget to remember to save sometimes...)

It is as it looks, it is not a suggestion to enhance the sstate which I think very difficult and maybe not worth the trouble of trying... the idea is protecting the user against him/herself.

But the really important is understand the nature of sstates and know it was never meant to replace the normal saves. Knowing this is yet more important while the emulator is in heavy development phase and can't grant the memory structure is always the same, which is the cause of sstate incompatibility in between versions (actually even between SVN builds).

The user must know a normal save is particular to each game, only what is absolutely needed to "rebuild" the position is saved, like char stats, times, the actual save point... and so on... in a fashion where not even the actual characters position is saved and the rebuild always place them in a defined position. This grant whatever was corrupted in memory (other than those things actually recorded) is gone when a normal load is done. The game is reconstructed from the disc content (supposed to be protected and never corrupted) and the memory "cleaned".

1 - SO, even when everything looks OK, be used to make a normal save followed by a normal load and then a fresh sstate in a timely base, to grant the last is so "Clean" as possible.

In a savestate, whatever corruption that got into the memory is "saved" and returns as soon the corrupted sstate is loaded, and with time those corruptions may accumulate...

2 - So, follow 1 to grant the state is always clean.

PS: to be in the secure side, an addendum to the advice to save and reload from memcard... "Always" quit the emulator altogether in between, may not be enough to reset or do a fast boot.
Imagination is where we are truly real
Reply
#10
Quote:It's a bit unfair to say it should be more secure than the memory content it saves... ideas how to enhance the sstate mechanics are welcome...

corrupt memory accumulation during emulation isn't unusual and there are things that can be done to minimize them (improving accuracy for instance and doing profiled leak tests during the development phases. (which im sure is done, which is why pcsx2 has as few problems as is compared to other projects....)

this issue, now, after doing a filemon trace is because the open handl on the file is not closing when the write completes after a period of time, or sstating many times during an emulation session, leaving the file subject to corruption due to power cuts. whilst the write handle is open, a portion of it is remaining in write cache waiting for more data. this is also why you're getting setting change losses Shadow lady, the issue does not occur during a process crash because the handles are force closed.

i would assume the state itself is complete, but a small amount of junk data ends up at the file end.
Reply




Users browsing this thread: 1 Guest(s)