just as the title. Sometimes I find sets of files that report that there is enough files to repair but when the autorepair cycle completes it reports that there is still a repair required.
Checking and unchecking autorepair (sorry but this is just become a habit now of how to start repair) instigates a second recovery.
In all instances so far (of which I estimate about 3 occurances) a second repair has been succesful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When this happens, does it report that it requires less recovery blocks to repair after the first attempt?
Can I suggest that the next time this happens, you do the following:
1) Immediatly after the first repair attempt, make a backup copy of all files in another folder.
2) Delete the repaired files and rename the .1 files removing the .1 file extension. This should put you back to the state before the first repair attempt.
3) Run the repair again.
4) Do a binary file comparison of the repaired files from the second attempt with those from the first attempt.
Report the results.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only cases of failed rebuilds that have known answers are due to bad RAM. Since you can get it to rebuild correctly with enough tries, this suggests that the PAR2 files are fine your RAM is bad. If your computer isn't doing anything important for a few hours you might test the RAM with that tool.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
just as the title. Sometimes I find sets of files that report that there is enough files to repair but when the autorepair cycle completes it reports that there is still a repair required.
Checking and unchecking autorepair (sorry but this is just become a habit now of how to start repair) instigates a second recovery.
In all instances so far (of which I estimate about 3 occurances) a second repair has been succesful.
When this happens, does it report that it requires less recovery blocks to repair after the first attempt?
Can I suggest that the next time this happens, you do the following:
1) Immediatly after the first repair attempt, make a backup copy of all files in another folder.
2) Delete the repaired files and rename the .1 files removing the .1 file extension. This should put you back to the state before the first repair attempt.
3) Run the repair again.
4) Do a binary file comparison of the repaired files from the second attempt with those from the first attempt.
Report the results.
Obviously I cant predict when this will happen again but rest assured when it does I will have a go at doing what you say :)
http://www.memtest86.com
The only cases of failed rebuilds that have known answers are due to bad RAM. Since you can get it to rebuild correctly with enough tries, this suggests that the PAR2 files are fine your RAM is bad. If your computer isn't doing anything important for a few hours you might test the RAM with that tool.