Nothing doing bug
Status: Beta
Brought to you by:
erdem_ua
Menu
▾
▴
Himm.
What operating system do you use?
Can you execute program via shell/terminal for debugging? (True for lınux and mac but windows)
Is it happens at every MKV file or just one of them?
Might be your MKV is not MKV at all. There is some files at internet, that is actually AVI or WMV video file but has MKV extension. Do you sure about the file is really matroska file? (Could be identified my MediaInfo utility or similars)
Thanks
The win32 version has a 2GB limit. This is because seekg and tellg when compiled as win32 have only int32 parameters.
@nosh: I don't think same. AFAIK, I remember that I read > 4GB files with standard library on win32 with mingw g++. M$ Visual Studio has a bug like that, It cannot read files >4 gb ( or 2 GB) with tellg. But Mingw uses fileoffset which is uint64_t. Since I don't use VS at compilation, I don't expect a bug like that.
Do you debugged the Meteorite executable actually?
No, I'm not familiar with the Code::Blocks, MinGW, WxWigdets environment. I tried some mkv-files and the files below 2GB worked and the aboves show the aforementioned problem. Then I looked at your source and saw that you used 64 bit variables so I assumed that it is the tellg/seekg problem. But you are right, a short test program shows that ios::off_type at MinGW has sizeof 8 bytes. So there must be another problem.
My system Win32. Meteorite cant handle files over 4gb. Try some other mkvs. I can try do it on Linux.
it does indeed have this problem with all the mkvs i have passed to it. using win7 x64, or winxp x86... doesnt seem to matter. the mkvs are 1.5gb, and have been encoded by handbrake.
I tried lots of MKVs and none of them unrepairable. I think this is Windows bug. Will solved in next release I wish.
This is really weird thing.
I have no problems in linux and program could fix every MKV file that I dropped in.
I don't make windows test much. But I tried once and it's worked. Will test better at next version.
For some mkv files buffer (bfr_size) is too small. The memory gets corrupted and the while loop in TreeParserChunkMaster gets endless because of "processor == NULL".
well from what i notice, all it does is hog processor 100% on a single core, and achieves nothing. the program doesnt hang, so it must be threaded, but it certainly isnt doing a thing. this is on windows of course. looking forward to seeing a released fix.
as you have updated the main page with this bug, be aware it is not only win7 related, it doesnt work on winxp either.
My system XP SP3, Core Duo 2.66ghz, 3gb ram.
I can successfully fix 7 GB movie under linux. I installed 7 my laptop (what a shame) & gonna try to fix it under win7.
Hi, nice program, when will next ver. be out and will that ver. be win 7 64bit compatible?
thx again, great work!!
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
Hi Erdem,
same Problem on Windows XP SP3 (Athlon 64X2 Dual)... the Program hangs on 50% CPU and do nothing (progress bar is grey)
I try some *.MKV's with the same result
Sincerely
Tomy
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
same Problem here
I'm using Win7 x64
cannot repair any mkv files. Would be really nice for a fix :)
Thanks
Firstly, sorry for all for this crap tool, I make it for linux, not windows mainly. But it needed to work as http://divfixpp.sf.net tool. Unfortunately, I give up meteorite coding for a while. I have another project(s) that has not released for a year. Which is http://wxhexeditor.sf.net . This tool particularly important for me. It's the hex editor behind DivFix++ and Meteorite, It make me understand meteorite files. I am also coding at SamyGO PVR tool that add video play capability... etc..
I wanted to say that this tool really works on linux, I don't make it windows or macOSX tests, only compiled and put it online at my birthday, for give a prize to humanity :) Tool will be compatible with all those Os'es when reached beta.
There is also logic errors at algorithm this time. I will turn back the coding Meteorite near april or one night that I don't wanted to sleep. But first, wxHexEditor needed to be reach usable levels.
Thanks all.
This days I also start my high license program at university. Also needed to give release wxhexeditor 0.08 asap :)
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
Hi erdem,
It is true Your tool works fine under Linux OS.
But there was an problem with Executive Decision 1996.720p HDTV x264-RuDE.
In this rar file part 03, 25 and 56 of 56 have crc errors.
After running Your tool the fiel was repaired but in the second crc error on file 25 h264 and ac3 file have not the same lenght.
The ac3 file is 700 ms longer than the h264...was hard to fix by feeling ;)
I hope this help You
Sincerely
Tomy
Last edit: Anonymous 2017-06-08
Tested under 7 x64 and verified.
Solution will ETA 2 Month from now because of final exams.
I see the same problem on two of my machines, Win 7 64 and Win XP 32 SP3. However I let the program run for a while, I had a MKV that had a lot of graphic corruption and it was unwatchable. I let Meteorite work on it overnight and then I watched the movie. There was no corruption left whatsoever. The movie was perfect. So I really don't know if it worked on the original file or not, that seems impossible given that it didn't create a new file and the file wasn't modified (last modified date didn't change). I just wonder how or what could have had that effect.
After I'm in urgent need to fix some MKV's i started digging into this issues (and finally was able to build the source under Win).
The 'sits and does nothing' issue seems rather simple: The problem is the composition of the outputfilename. It assumes the path-delimiters to be '/' in the sourcefilename. Actually these are '\' the result is quite screwy -> invalid filename.
The case that the outputfile can not be opened is not handled correctely, to meteorite tries over and over and over .....
If I remember correctly, I changed that output file delimiters as '\' at windows binary compilation.
So the source does not corresponds %100 for Windows build. Also Windows build released later than Linux release because of that problem... I changed source slightly for compilation on with mingw..
If this is the real problem, than Windows binary builds does not work for any files. But in WinXP its working properly. Also it work on vista too. (I tried by Vista.)
And also if there is problem with opening file target file, code does not retry to open it. Or does it? I forget the code flow actually. Do you check that with gdb in win?
Well, I did not do any deeper investigations on what might run with XP and what not.
As a matter of fact, the released binary is not working on my machine, the recompiled is.
Maybe it was not the delimiter, but some compileroption - or issue with the wxwidgets version used for the release.
What happens with the illegal output-file name is that after it was not possible to open the out-file the whole process is starting over and over using the current input file. Looks like after the OF-error is detected the IF is not kicked from the todo list.
What do you use for compiling? Which compiler and version? (Mingw, Cygwin, VC)
I'm using MinGW with gcc 3.4.5.
Meanwhile I found a second issue: On one of the files I tried to fix Meteorite gets stuck and never recovers with the error "Error on TreeParserChunk();" .
I'm trying to dig into this tonight.