Weird error copying MKV file
I have some locally stored media i was copying between drives and one mkv file gave this error error reading 'video1.mkv': Input/output error and only copied 176/256 MiB; the copied file plays the video only up to a certain point before abruptly closing;
I can play the original file fine albeit there is a noticeable hitch at that point but the video plays normally till the end
I have tried zipping the file but it fails to zip it
I tried copying it using ffmpeg but it also gave the same error
I can copy the file in the same directory but trying to copy the copy also gives the same error
I tried copying to a variety of different storage drives and it still gave me this error any ideas?
Seems like there's some bitrot in the middle of the file, and whatever you're using to play back the original file just skips it and doesn't care enough to halt playback. You might try looking for ways to restore as much of the file as possible with something like this, assuming the mkv is a unique copy that you can't get anywhere else.
Edit: I'm also curious if this file lives on an XFS/BTRFS/ZFS filesystem. The reflink property of these filesystems may be the reason that you can copy within the same folder without it throwing an error.
Yes it lives on BTRFS, I tried a few solutions but some gave this
Read error Error demuxing input file 0: Input/output error video1.mkv: Input/output errorand other things i tried said that i dont have hevc support(Yay Fedora) I might be wasting more time than necessary on the file.so i might just give upWhat are the results of a scrub on the filesystem? I'm not familiar with BTRFS, but use ZFS, and a scrub is where I would start in your shoes.
I did a scrub and this is what it showed when i ran
btrfs scrub status:Duration: 0:17:54 Total to scrub: 63.82GiB Rate: 60.85MiB/s Error summary: read=528 csum=48 Corrected: 570 Uncorrectable: 6 Unverified: 0Aaaah that's a drive that should go in the dumpster asap.
Is the file still borked? Could just be the filesystem, but I'd look at the drive next.
Wonder if SMART uncorrectable errors count is high and the drive is failing.
Fair enough. I would at least try to get the damaged file off of the disk so you can potentially fix it later, or just have it available to play in its broken state. For the future you should probably be running monthly BTRFS scrubs to detect bitrot sooner, and potentially you should have some backups or data redundancy so you can repair the bitrot when it's detected.
I did a BTRFS scrub on the partiton and this is what came up
Duration: 0:17:54 Total to scrub: 63.82GiB Rate: 60.85MiB/s Error summary: read=528 csum=48 Corrected: 570 Uncorrectable: 6 Unverified: 0I dont know what else to do from hereIt goes without saying but the number of errors you should get on a scrub is ideally 0. Bitrot happens from time to time which is why you should keep some data redundancy/backups so you can repair it when it's detected, but that number seems higher than normal. Your disk may be going bad if you're getting that many read errors; I'm not sure. I believe you're already backing up data off this drive but yeah I would get everything important off the drive ASAP, then run a SMART short test and a SMART long test to see if that reports that anything is wrong. The disk may be fine but better to be safe than sorry.
Back to the video file, I'm assuming it was not one of the ones that BTRFS fixed automatically? The only real options for data recovery are to rescue the file minus the bad blocks with e.g.
ddrescue(which I don't personally have familiarity with) or something similar, or to encode through the errors with ffmpeg if it will let you.A SMART Test showed 6 bad sectors but overall disk assessment was ok(I dont think there is any connection between the file and the HDD), yes that file has not been fixed, the disk in question used to be my main bootdrive a few days ago, I shrunk the partition and created a new EXt4 and i am slowly copying files that are worth keeping, i removed the ODD from my laptop and installed a caddy, intend to use it as a second drive(The file in question has no sentimental value)
Okay cool. I would be wary of that drive just in case, and I would definitely schedule weekly SMART short tests and monthly BTRFS scrubs on it if you go with BTRFS in the future. EXT4/XFS/etc do not have a concept of data checksums, which means they can't scrub and check for bitrot - this might be problematic if you find that your disk starts causing bitrot because you won't know where it's happening.
I follow Backblaze's rules on detecting impending drive failure:
If any of these SMART metrics are higher than 0 I'd expect failure soon and take precautions.
Thank you Id 197 and 198 reported 5 & 6 respectively(bad sectors decreased from 6 to 5), Is it possible to copy a file non sequentially; say back to front so i can just join those 2 parts together?
Try this answer. I guarantee there is a way to read the file front to back while skipping errors, but I run so much data redundancy that I don't have any experience with it.
Thank you
Thank you I think i might distro hop considering how many problems fedora is giving me, as for the file; it refuses to budge, i have found another such file within the same set, i might just leave it there for future me.
Can't you install RPMFusion codecs and "fix" that?
It's very likely that your disk is failing.
dd if=/path/to/file.mkv of=/new/file/path.mkv conv=noerror,sync bs=4kShould give you a file with just the damaged bits missing.
Did you try copying it with dd/ddrescue?
Is the copied file going to a usb? Is the usb fake? Otherwise I'm pretty sure your source is bad. Probably the disk sector if you're sure the file was at some point complete.
Something like btrfs probably does block cloning or similar so a copy to the same disk probably just points at the same disk blocks as the original.
Check the source probably