All my .mkv files are unplayable after renaming

[dstaver]

I renamed all my movies and tv shows - all .mkv files - to a jellyfin structure and after renaming the movies are now unplayable. The TV shows still play for some reason.

• Files are located on a Seagate Personal Cloud NAS shared to windows with SMB
• Renamed the files using format:

  Code: Select all

  {drive}/{jellyfin.id}

• After renaming the files were unplayable
• Reverting the rename operation did not fix the files
• Byte size is identical, but hash is not
• The same operation done on local drive does not corrupt the file
• The same operation done on network drive, starting filebot with -no-xattr does not corrupt the file so this is probably the issue
• Using mkvalidator on the files reports ERR003: EBML head not found! Are you sure it's a matroska/webm file?

So it seems like I can avoid the issue in the future by starting filebot with -no-xattr but I now have 1.7tb of unplayable movies. Is there any way I can get those fixed?

[rednoah]

Files are located on a Seagate Personal Cloud NAS shared to windows with SMB

What model of Seagate Personal Cloud NAS are you using? Are you using the latest firmware? I found Personal Cloud Hard Drive but that product line is End-of-Life effective July 18th, 2022.

The same operation done on network drive, starting filebot with -no-xattr does not corrupt the file so this is probably the issue

In theory, xattr metadata and file content are separate and modifying one cannot affect the other. In practice, the server-side SMB implementation can be faulty. NTFS Alternate Data Streams is a rarely used file system feature that the Seagate developers seem to have enabled but perhaps forgot to test thoroughly.

I am aware of at least one report from many years ago, I forgot which product, where files were incorrectly displayed as 0 bytes in the directory view after NTFS ADS were set. As far as I remember, files were still readable though (as long as the software didn't check the file size before reading the file) and removing the NTFS ADS made file size queries work correctly again. That is to say, a faulty SMB implementation - though extremely rare - is possible.

Byte size is identical, but hash is not

Using mkvalidator on the files reports ERR003: EBML head not found! Are you sure it's a matroska/webm file?

If the hash has changed, then some bytes were overwritten with different bytes. That is a very bad sign. EBML head not found! probably means that the file doesn't start with a MKV header, so that would suggest that the first few bytes have been overwritten at the very least.

What happens if you create a new 0 byte *.mkv file and then rename that on the NAS?

Can you share a short *.mkv video file pair before / after corruption so we can compare the files in a hex editor?

What happens if you Read / Write NTFS Alternate Data Streams yourself with PowerShell? You could try small (a few bytes) and large (multiple kilobytes) attribute values to see if you can trigger the corruption on purpose.

[dstaver]

Thanks for replying.

I tried creating and renaming a 0 byte file. Still 0 bytes.

A small test file did not get corrupted.

I think I won't spend much more of my time, or yours, debugging this. The movies can be redownloaded so I didn't really lose anything critical. The NAS is over a decade old and EOL was years ago, I'll look into replacing it with something more modern.

[rednoah]

I think I won't spend much more of my time, or yours, debugging this.

I'd be very curious as to what's going on under the hood. Do a small video files from https://test-videos.co.uk/bigbuckbunny/mkv corrupt / not corrupt at different file sizes? If it only happens with larger files then it would be interesting what the size limit is, and of course what the actual corruption is, but no worries if you don't have time, at this point it's more about curiosity.