mkvmerge gui is corrupting my mkv files when muxing

[steve1232]

So all I am doing is adding subtitles and removing foreign language audio tracks from my mkv files and 1/3 to 1/2 of the time it will corrupt them. I have noticed when I play these corrupted remuxed videos in VLC in certain places it will stop playing the file as if the video has finished when there is still time to go, every time the damage will be in a different place even if the same file is remuxed

When I open the damaged videos file in a hex editor and compare them to the original, I notice a bunch of hex code has been replaced with a bunch of "00" (so mkvmerge doesnt verify the file after it is finished writing it or it would catch this), but why is it doing this in the first place?

I ran a memory check and it found no problems I don't know why mkvmerge gui would replace a bunch of video code with 00's when remuxing, corrupting the file. I only caught this after 500G of files were damaged which is very annoying, now I must play every file I remux from start to finish to make sure it doesn't stop before the end, because I can find no program that catches this type of mkv damage and will warn me the file is damaged.

mkvmerge gui log shows no errors for these damaged files. I reinstalled mkvmerge gui and updated to the latest version and there is no improvement

[johns0]

I've never had a corrupted mkv file using mkvmerge,must be something else wrong in your computer system,sometimes it can be your virus scanner screwing up the files or something else.

[steve1232]

What would be the best way to track down the cause of the problem?

My problem looks exactly like this bug tracker ticket https://trac.bunkus.org/ticket/830

Memory test turned out fine, virus scanner is Microsoft's basic virus scanner, I can't think of anything else that could do this

[Selur]

If you got the same problem, it might be a good idea to provide the mkvtoolnix author with a sample that allows him to reproduce the problem.
Other than that you can try to do your remuxing using ffmpeg.
MSE doesn't cause any problems with mkvtoolnix here,.. got any other software which could interfere, like a misconfigured personnel firewall?

[El Heggunte]

Selur is right, probably some piece of software can be interfering with mkvmerge.

I have already seen a poorly-coded Windows "desktop gadget" make GCC miscompile everything ,
so it's not impossible something similar is happening on your computer...

In the past similar issues were often due to faulty hardware, so that's another possibility to consider.

[steve1232]

I am using Comodo firewall with program defense turned off, so I don't see what it could possibly be doing to interfere with muxing, but after disabling it I havn't had any such corruption after muxing 10 files, when usually I would have at least 2-3 corrupted. So, there is moderate possibility that comodo firewall is to blame

Can anyone think of a better method of detecting the corruption I described, other than playing the video at 32x speed in vlc just to see if it stops playing before reaching the end? My concern is that some slightly corrupted mkvs may pass such a test

--
Edit: ok, I just had a corrupted one with comodo firewall turned off, it seems to happen more when I mux from my main disk to an external hard disk, and less when I mux to my main hard disk with the original file on it

[gonwk]

Hi Steve1232,

What version of MKVTool are you using? Installer type or Portable and version?

G!

[LUCHOO]

Problems with VLC or with some hardware players, read solution here:


https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590

[Rose02]

Hi all.
I have the same probem. I always had it also with other mkvmerge GUI versions.
Problem is not due to dummy elements as stated here https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590, this does't resolve the issue.
Neither it's due to system configuration (firewall, antivirus, etc.). I have it with three different PCs.
I think it's simply a program bug that randomly occurs. I have approx 2 file corrupted out of 10.
The only way for me to be sure the muxed video is ok, is to playback it at 1x speed. Also playing it at 32x I'm not 100% sure it is definitely ok.

This is quite annoing and frustrating.

Bye

[Selur]

then upload a sample which allows to reproduce the problem, so one can be sure it's really not a system setup problem,...
if you can't reproduce the problem with a specific file again, it's probably a RAM problem,..

[Rose02]

Yes, I could be, but hard to think with 4Gb RAM and no other application running.
The problem occurs random, it's very hard to reproduce it with the same file.

Thank you for the reply.

[Selur]

" very hard to reproduce it with the same file." = randomness doesn't sound like a mkvmerge bug

[Rose02]

Ok, can you suggest a tool to check if .mkv muxed file is ok?
Thank you

[Selur]

How does the corruption show?

[Rose02]

Simply VLC stops playing the video at the point it is corrupted (i.e. after 3m48s), and the black VLC window is displayed (same with WMP).

Thank you

[david3]

For what its worth, I've had the same problem with mkvmerge for a long time. As other say, it seems to be random, but happens often.

What I've been doing so far to work around the problem is run mkvalidator after remuxing, and the ones that show problems, I remux again (from the original source file, not the one with the problem).

http://www.matroska.org/downloads/mkvalidator.html

[Rose02]

Thank you for the tip.
This will help a lot.

Regards

[david3]

I created a .bat file to check all of the .mkv files in a directory and output the results to a log.txt file to make it easy when I've got a batch of them to check:

echo off
FOR %%f in (*.mkv) DO (
  echo %%f
  echo %%f >> log.txt
  {path to mkvalidator}\mkvalidator.exe --quiet "%%f" 2>> log.txt
  echo ----- >> log.txt
)
echo on

(update the path for mkvalidator before using, and run from the directory you want to check).

If I want to check everything, I use a different version to check subdirectories recursively:

echo off
FOR /r %%f in (*.mkv) DO (
  echo %%f
  echo %%f >> {path to log file directory}\log.txt
  {path to mkvalidator}\mkvalidator.exe --quiet --no-warn "%%f" 2>> {path to log file directory}\log.txt
  echo ----- >> {path to log file directory}\log.txt
)
echo on

(update the path for mkvalidator and log file directory before using, and run from the directory you want to check -- including subdirectories).

You can change the "--quiet" and "--no-warn" options as you like. I use the extra "--no-warn" when I'm checking everything to avoid the constant but harmless "WRN0D0: There are 5125 bytes of void data" that I get on every file repeated for thousands of files (though it will suppress more serious warnings, too).

[david3]

Also, it may just be my imagination, but the problem seemed to happen less often on an exFAT volume than on an NTFS volume, so I use a separate drive formatted with exFAT for staging the files and remuxing.

The drives I'm using are external USB drives as the only internal drive I have is an SSD and it doesn't have enough space for lots of large video files.

[Rose02]

Thanks a lot.
I'll try it for sure.

Bye

[Sco]

Sorry to bump an old thread, but this is 100% whats happening to me, and its frustrating as hell. You'd think they'd have sorted this out in the versions over the past *!3!* years.

I remuxed over 100 TV series, doing each episode-by-episode, making sure the audio tags were correct(kodi automatically plays english ones for me, so its important they have that flag) and integrating the sub files... All to find out, when i actually sit down to watch through a TV series, ~1/3 of them were RUINED by the damn thing. Not only did i waste hours fixing all the files, but now i need to re-acquire the files too.
And even in the videos where it does not just abruptly stop, there are a few instances of artifacts and scrambled frames that are not seen in the source files.

Anyone know why this happens?

[hello_hello]

Sco,
It's all guesses without a sample. Can you upload one somewhere? Just split a small section off if you can. It doesn't need to be large, just a section that doesn't play properly.

As I run XP I'm still using MKVMergeGUI 7.8.0 but it's never caused a problem I'm remuxing MKVs a lot.

Are you only using Kodi or have you tried another player?

[Rose02]

This is definitively an issue of mkvmerge GUI (the player is not relevant), experienced in several years of muxing activity.
Never fixed, neither admitted by developers.
I suspect it mostly occurs with files stored in external HDD.
The only workaround I know is mkvalidator tool, it works pretty good.

Bye

[El Heggunte]

IMHO, it's still too early to blame MKVmerge... because possibly the cause of the data corruption is in Windows itself

So far, I have seen complaints about MKVmerge's apparent "data corruption" when writing to external HDDs
only from users of Windows

I have never examined the source-code of MKVtoolnix, but I doubt that it does not call /use the reading++writing functions already present in the target operating system(s)

[hello_hello]

This is definitively an issue of mkvmerge GUI (the player is not relevant), experienced in several years of muxing activity.
Never fixed, neither admitted by developers.
I suspect it mostly occurs with files stored in external HDD.
The only workaround I know is mkvalidator tool, it works pretty good.

Bye

"I suspect it mostly occurs with files stored in external HDD."

To mean that'd mean "look elsewhere" as I'm not sure why MKVMergeGUI's behaviour would change.
Does "stored" in external drive" mean MKVMergeGUI wrote the files to the drive, or were they written, then copied to the drive?

There's a thread here about Win7 64 bit not always behaving with external USB3 drives, and I've seen similar threads elsewhere. I wonder if that could be related?

[david3]

It's been a few more years now, and I think 99% that this is a bug with the NTFS file system and external USB drives that seems to be exasperated when muxing files with mkvmerge.

I reformatted my external USB drives with exfat and the problems stopped. No data corruption problems for the past few years. And I run mkvalidator on all my files after they are mkvmerged.

[david3]

To mean that'd mean "look elsewhere" as I'm not sure why MKVMergeGUI's behaviour would change.
Does "stored" in external drive" mean MKVMergeGUI wrote the files to the drive, or were they written, then copied to the drive?

There's a thread here about Win7 64 bit not always behaving with external USB3 drives, and I've seen similar threads elsewhere. I wonder if that could be related?

I think the external USB drives are suspect whenever they touch the files, read from/written to/copied to or from.

I don't think it matters if it's USB2 or USB3. My external drives are using USB2.

But I think it's only a problem when the drives are formatted as NTFS. exFAT works better and I haven't been experiencing the data corruption since switching to it (for external drives).

[Rose02]

But I think it's only a problem when the drives are formatted as NTFS. exFAT works better and I haven't been experiencing the data corruption since switching to it (for external drives).

Good to know.
Thank you.

[Sco]

Hey again.
I did most of my remuxing on a external NTFS hdd(as the source AND as the location for the complete file) but i tried re-doing it with some of my re-acquired content on the internal SATA drive, and it still came out with issues(played fine, but there were missing frames). I should add my system is anemic(Its just an old netbook i use to torrent with. AMD C-50 chip and 4gb of ram on Windows 7-32bit) but the time to remux the files was insignificant(literally less time than it took to open the next file, deselect the useless junk[like chapters and tags] and set the proper language flag for the audio streams) so i wouldnt think it would be from lack of processing power.

Either way, i'm about 1/6th done re-acquiring the content... Though theres some stuff i'll probably never be able to get back as it was downloaded years ago and the source for it is no longer up.

I had opened up a thread on the official mkvtoolnix github forums, but the owner said he was closing it since even though he has heard others complain about it, he was never able to replicate it... I guess he thinks its just a conspiracy to make his program look bad?

[codecpage]

The problem certainly exists (or, existed, because I didn't have any issues so far since using the version with the new GUI, e.g., 8.6.0; but I can't say if it may be related to external drives, as I do most multiplexing on a large internal one).

I even experienced some seconds of another, formerly deleted (!!) video file inserted into the file multiplexed. Repeating the very same multiplexing very often made the error disappear. This is absolutely weird and appears to be an problem with elementary file system handling, otherwise it couldn't access deleted files. As MKVtoolnix appears to be developed under Linux, this could have been a bug in an NTFS file system driver or some buggy code produced by a compiler.
I remember several earlier Linux operating sytem versions warning about issues when accessing NTFS.
If it were Windows itself causing the problem, other software also would have problems like this. But I'm not aware of any such issue. I use Windows 7.
That said, MKValidator is about the only quick tool to check for errors. BTW, I noticed that it gave lots of warnings when checking files from the old GUI version of MKVtoolnix, but hardly any with files produced with the new one.
-----------------
codecpage.com