VideoHelp Forum

+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 49
Thread
  1. 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
    Quote Quote  
  2. I'm a Super Moderator johns0's Avatar
    Join Date
    Jun 2002
    Location
    canada
    Search Comp PM
    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.
    I think,therefore i am a hamster.
    Quote Quote  
  3. 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
    Quote Quote  
  4. 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?
    Quote Quote  
  5. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    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...

    Originally Posted by Mosu
    In the past similar issues were often due to faulty hardware, so that's another possibility to consider.
    Quote Quote  
  6. 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
    Last edited by steve1232; 29th Apr 2013 at 14:48.
    Quote Quote  
  7. Hi Steve1232,

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

    G!
    Quote Quote  
  8. Member
    Join Date
    Jan 2008
    Location
    Peru
    Search Comp PM
    Problems with VLC or with some hardware players, read solution here:


    https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590
    Quote Quote  
  9. Member
    Join Date
    Jun 2013
    Location
    Italy
    Search PM
    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
    Quote Quote  
  10. 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,..
    Quote Quote  
  11. Member
    Join Date
    Jun 2013
    Location
    Italy
    Search PM
    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.
    Quote Quote  
  12. " very hard to reproduce it with the same file." = randomness doesn't sound like a mkvmerge bug
    Quote Quote  
  13. Member
    Join Date
    Jun 2013
    Location
    Italy
    Search PM
    Ok, can you suggest a tool to check if .mkv muxed file is ok?
    Thank you
    Quote Quote  
  14. How does the corruption show?
    Quote Quote  
  15. Member
    Join Date
    Jun 2013
    Location
    Italy
    Search PM
    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
    Quote Quote  
  16. 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
    Quote Quote  
  17. Member
    Join Date
    Jun 2013
    Location
    Italy
    Search PM
    Thank you for the tip.
    This will help a lot.

    Regards
    Quote Quote  
  18. 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:

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

    Code:
    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).
    Quote Quote  
  19. 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.
    Quote Quote  
  20. Member
    Join Date
    Jun 2013
    Location
    Italy
    Search PM
    Thanks a lot.
    I'll try it for sure.

    Bye
    Quote Quote  
  21. Member
    Join Date
    Apr 2016
    Location
    Autralia
    Search Comp PM
    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?
    Quote Quote  
  22. 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?
    Quote Quote  
  23. Member
    Join Date
    Jun 2013
    Location
    Italy
    Search PM
    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
    Quote Quote  
  24. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    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)
    Quote Quote  
  25. Originally Posted by Rose02 View Post
    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?
    Quote Quote  
  26. 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.
    Quote Quote  
  27. Originally Posted by hello_hello View Post
    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).
    Quote Quote  
  28. Member
    Join Date
    Jun 2013
    Location
    Italy
    Search PM
    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.
    Quote Quote  
  29. Member
    Join Date
    Apr 2016
    Location
    Autralia
    Search Comp PM
    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?
    Quote Quote  
  30. 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
    Quote Quote