I hope someone can help, I am getting constant file verification errors. I am copying from a NAS drive to a local hard driver connected by a gigabit ethernet and a usb 3 drive. Done through interface on win10.
I (obviously) have file verification switched on. I thought this maybe because I had too many threads (switched on via the donate option), but now updating to the latest free version I still get the same error.
This isn't every file, it particularly seems to be for bigger files but not exclusively.
Copying the sames files with verify on with fastcopy works first time. I have been copying over network to NAS for several years but this has only started occurring recently.
Does anyone have any advice or need any further info? Thanks
File Verification Error
- Posts: 2
- Joined: 8 Aug 2020
- Posts: 943
- Joined: 8 May 2006
Have you verified the verification ;-) ?
As in have you run a hash check on two files that have failed verification to confirm the failure?
And then, have you physically compared the two files (with a file comparison program) to get a feel for just how extensive the differences might be?
If verifications fail, I'd think disk, memory, & or interface connection issues.
Other then hash check, & file comparison... if it is a media file, you can compare it "visually".
As a start, does it play? And then, does it play fully? (Media players have some resilience & may show glitches on bad parts of a file, or skip over, or outright fail... You can also run various checks on media which might point out issues - even though a file may look right.
[Something like ffmpeg -i "%1" -v error -f null -.)
As in have you run a hash check on two files that have failed verification to confirm the failure?
And then, have you physically compared the two files (with a file comparison program) to get a feel for just how extensive the differences might be?
If verifications fail, I'd think disk, memory, & or interface connection issues.
Other then hash check, & file comparison... if it is a media file, you can compare it "visually".
As a start, does it play? And then, does it play fully? (Media players have some resilience & may show glitches on bad parts of a file, or skip over, or outright fail... You can also run various checks on media which might point out issues - even though a file may look right.
[Something like ffmpeg -i "%1" -v error -f null -.)
- Posts: 2
- Joined: 8 Aug 2020
Thanks for your suggestion. Hash check is different, file content scan shows differences too. This is an MP4 video.
Any suggestion for software to do a compare? The file sizes are the same. I tried winmerge but it doesn't provide any seemingly deep analysis.
Any suggestion for software to do a compare? The file sizes are the same. I tried winmerge but it doesn't provide any seemingly deep analysis.
- Posts: 943
- Joined: 8 May 2006
As a start, both files appear to play correctly?
Windows?
MediaInfo (ZIP version might be the better choice).
Compare the output against both files.
(With the command line version, you could do something like:
mediainfo.exe file1.mp4 > file1.txt
mediainfo.exe file2.mp4 > file2.txt
then compare file1.txt against file2.txt)
Now that compares file "metadata" (if you will), & not the files themselves, but it still might help.
WinMerge should help.
WinMerge
https://postimg.cc/HJ7C0STG
Altap Salamander, among other things, has a File Compare feature.
https://postimg.cc/jLZKRwM1
What that points out to me...
tops of the files are the same, so it's not something like a file "tag" (metadata) has changed
it's not only a few bytes that are different
there is a large swath of data that is different, so in my mind, that points to actual file corruption
bottoms are the same
if it were a tag issue, you might expect to find diffs only at the top or only at the both of the file, perhaps within some particular range, like the first (or last) 4096 bytes
if it were only an odd byte or two difference, some odd random spots in the file (outside of where you might expect a tag change), you say, hmm?
(In this case, left is a valid file, right is an actual corrupt file - pulled from a failing HDD.
Same movie clip.mp4, same size, same date.
Both play - though the corrupt file may play from 0.00 to 1.33, then there is an area of corruption, timeline jumps to 3.44, with the file then playing its remainder through to the end at 5.22.)
Binary compare is usually must faster then text. So usually the better method to start off with.
Some media players (like Windows Media Player) have (or had ? I don't use it) the ability to go out & pull tag data from the net & "update" your media files - so changing them. So if you were to compare an original source file to a WMP changed file, they're different!
Tag diffs, only the very top of the files are affected:
https://postimg.cc/RJ3KPqLh
https://postimg.cc/fkFxVjM9
https://postimg.cc/JsCZqrD7, Salamander, Text mode
Windows?
MediaInfo (ZIP version might be the better choice).
Compare the output against both files.
(With the command line version, you could do something like:
mediainfo.exe file1.mp4 > file1.txt
mediainfo.exe file2.mp4 > file2.txt
then compare file1.txt against file2.txt)
Now that compares file "metadata" (if you will), & not the files themselves, but it still might help.
WinMerge should help.
WinMerge
https://postimg.cc/HJ7C0STG
Altap Salamander, among other things, has a File Compare feature.
https://postimg.cc/jLZKRwM1
What that points out to me...
tops of the files are the same, so it's not something like a file "tag" (metadata) has changed
it's not only a few bytes that are different
there is a large swath of data that is different, so in my mind, that points to actual file corruption
bottoms are the same
if it were a tag issue, you might expect to find diffs only at the top or only at the both of the file, perhaps within some particular range, like the first (or last) 4096 bytes
if it were only an odd byte or two difference, some odd random spots in the file (outside of where you might expect a tag change), you say, hmm?
(In this case, left is a valid file, right is an actual corrupt file - pulled from a failing HDD.
Same movie clip.mp4, same size, same date.
Both play - though the corrupt file may play from 0.00 to 1.33, then there is an area of corruption, timeline jumps to 3.44, with the file then playing its remainder through to the end at 5.22.)
Now, depending, a binary comparison program can get tripped up by a relatively small change between files in instances where they can't "re-sync". Say with a tag change where the file sizes do change. It could be that a tag change changed the size of a file, the tag is at the very top of the file, & even though it is only a very small actual change, a binary compare utility may get tripped up & say that "99%" of the file content is different. Where if you did a "textual" compare, that may be more apt to point out such a (negligible) change.large swath
Binary compare is usually must faster then text. So usually the better method to start off with.
Some media players (like Windows Media Player) have (or had ? I don't use it) the ability to go out & pull tag data from the net & "update" your media files - so changing them. So if you were to compare an original source file to a WMP changed file, they're different!
Tag diffs, only the very top of the files are affected:
https://postimg.cc/RJ3KPqLh
https://postimg.cc/fkFxVjM9
https://postimg.cc/JsCZqrD7, Salamander, Text mode
