Hi,
Since a few weeks i got often (not always) a verify failed error while repairing by Usenetexplorer.
But a repairing with Quickpar will works fine.
What could be the problem ? Some suggestions ?
Repairing files: verify failed error
does it succeed when you initiate repair manually from UE after you see the error (click the repaired set right button context menu -> repair).
do you save directly to hard drive or else?
also it cannot be you ran quickpar and UE on the same data in the same time or files changed between UE saved them and when the files were being repaired.
RAM: UE is faster than quickpar, the code is similar but it may use more memory if you allow it, then the probability of getting error will increase when RAM is faulty. also if you get error rarely so chance of succeding is high - trying repair again would likely to succeed whether you use quickpar or retry UE repair option manually, but if you used quickpar on permanent basis you could well get the same rare verify failed errors.
Disk: When files are ok UE verifies them during save so if there is some problem with the storage so they are not written right, and then the set needs repair those files which UE things are good will cause verify error, but it also means files can be corrupted e.g. when copying them to the storage so it doesn't make sense to verify files were written ok, because they could be corrupted in many other ways as well. quickpar cannot verify on fly like UE, so it reads files from disk every time, then with faulty storage you'll get "better" results at the expense of a lot of unnecessary disk reads.
in short if you save to hard drive and you cannot suspect any interferences (like antivirus corrupting saved files) try to test RAM in the same conditions when you saw UE gave verify error.
do you save directly to hard drive or else?
also it cannot be you ran quickpar and UE on the same data in the same time or files changed between UE saved them and when the files were being repaired.
RAM: UE is faster than quickpar, the code is similar but it may use more memory if you allow it, then the probability of getting error will increase when RAM is faulty. also if you get error rarely so chance of succeding is high - trying repair again would likely to succeed whether you use quickpar or retry UE repair option manually, but if you used quickpar on permanent basis you could well get the same rare verify failed errors.
Disk: When files are ok UE verifies them during save so if there is some problem with the storage so they are not written right, and then the set needs repair those files which UE things are good will cause verify error, but it also means files can be corrupted e.g. when copying them to the storage so it doesn't make sense to verify files were written ok, because they could be corrupted in many other ways as well. quickpar cannot verify on fly like UE, so it reads files from disk every time, then with faulty storage you'll get "better" results at the expense of a lot of unnecessary disk reads.
in short if you save to hard drive and you cannot suspect any interferences (like antivirus corrupting saved files) try to test RAM in the same conditions when you saw UE gave verify error.
still there should be some underlying cause, when RAM usage is higher there is lower chance par2 repair will have to split repair blocks into smaller blocks to fit matrix operation into RAM, but it doesn't affect the result.
if it is not accidental - it means files are written ok into the disk (since when saving nothing depends on RAM usage), but something goes wrong with repair, if all ok with the disk then it could be RAM, maybe increasing the size reduced the probability of hitting a faulty address.
hardware problems are sometimes tricky to detect, e.g. i have a computer which shuts down by itself around once a month, maybe because of faulty hard drive, still don't know what it is for sure.
if it is not accidental - it means files are written ok into the disk (since when saving nothing depends on RAM usage), but something goes wrong with repair, if all ok with the disk then it could be RAM, maybe increasing the size reduced the probability of hitting a faulty address.
hardware problems are sometimes tricky to detect, e.g. i have a computer which shuts down by itself around once a month, maybe because of faulty hard drive, still don't know what it is for sure.