this post was submitted on 01 Nov 2023
24 points (92.9% liked)

Linux

48691 readers
667 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
24
Weird error copying MKV file (lemmy.ml)
submitted 1 year ago by [email protected] to c/[email protected]
19 comments fedilink hide all child comments
 

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?

top 19 comments
sorted by: hot top controversial new old
[–] [email protected] 13 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago) (3 children)

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 error and 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 up

[–] [email protected] 7 points 1 year ago (1 children)

What 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.

[–] [email protected] 5 points 1 year ago (2 children)

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: 0

[–] [email protected] 5 points 1 year ago

Aaaah that's a drive that should go in the dumpster asap.

[–] [email protected] 3 points 1 year ago

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.

[–] [email protected] 5 points 1 year ago (2 children)

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.

[–] [email protected] 2 points 1 year ago (1 children)

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: 0 I dont know what else to do from here

[–] [email protected] 5 points 1 year ago (1 children)

It 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.

[–] [email protected] 2 points 1 year ago (1 children)

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)

[–] [email protected] 4 points 1 year ago (1 children)

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:

  • SMART 5: Reallocated_Sector_Count.
  • SMART 187: Reported_Uncorrectable_Errors.
  • SMART 188: Command_Timeout.
  • SMART 197: Current_Pending_Sector_Count.
  • SMART 198: Offline_Uncorrectable.

If any of these SMART metrics are higher than 0 I'd expect failure soon and take precautions.

[–] [email protected] 1 points 1 year ago (1 children)

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?

[–] [email protected] 2 points 1 year ago (1 children)

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.

[–] [email protected] 2 points 1 year ago

Thank you

[–] [email protected] 1 points 1 year ago

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.

[–] [email protected] 2 points 1 year ago

i dont have hevc support(Yay Fedora)

Can't you install RPMFusion codecs and "fix" that?

[–] damium 9 points 1 year ago

It's very likely that your disk is failing.

dd if=/path/to/file.mkv of=/new/file/path.mkv conv=noerror,sync bs=4k

Should give you a file with just the damaged bits missing.

[–] [email protected] 3 points 1 year ago

Did you try copying it with dd/ddrescue?

[–] [email protected] 1 points 1 year ago

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.

ffmpeg -v error -i file.avi -f null - 2>error.log

Check the source probably