Posts: 2
Threads: 1
Joined: May 2011
Reputation:
0
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
Posts: 9.760
Threads: 163
Joined: Dec 2008
Reputation:
154
05-04-2011, 03:32 AM
(This post was last modified: 05-04-2011, 03:32 AM by Shadow Lady.)
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
Posts: 2
Threads: 1
Joined: May 2011
Reputation:
0
Aw man, thanks anyway! I should have thought about backing up the saves.
Posts: 3.028
Threads: 9
Joined: Jul 2009
Reputation:
49
It's sadly the nature of save states... They were never designed to completely replace memory card saves.
Posts: 3.559
Threads: 21
Joined: Jul 2010
Reputation:
61
Location: Australia
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
Posts: 3.559
Threads: 21
Joined: Jul 2010
Reputation:
61
Location: Australia
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).
Posts: 9.760
Threads: 163
Joined: Dec 2008
Reputation:
154
05-05-2011, 10:38 AM
(This post was last modified: 05-05-2011, 10:40 AM by Shadow Lady.)
(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
), but only PCSX2 inis, plugins are always fine.
Core i5 3570k -- Geforce GTX 670 -- Windows 7 x64
Posts: 4.504
Threads: 14
Joined: Jul 2009
Reputation:
89
05-05-2011, 03:04 PM
(This post was last modified: 05-05-2011, 03:19 PM by nosisab Ken Keleh.)
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