v0.33 & 0.34 very slow on 4core/4GB Win7x64
Brought to you by:
erdem_ua
Menu
▾
▴
#24 v0.33 & 0.34 very slow on 4core/4GB Win7x64
I've been using DivFix++ for a few years with happy results on WinXP x32. I recently installed v0.34 x64 & x32 on a new Win7x64 Intel 4core system with 4GB RAM. It generally works, but is really, really slow. What used to take a minute or two on the XPx32 Dual Core with 2GB RAM, now takes 15-20 min or more on the faster system. Similar results with both x32 & x64 versions both with and without admin privileges. I tried downgrading to v0.33x32 with very similar results...works, but really, really slow. Just for comparison, the same AVI can be "fixed" by VDub Direct Stream Copy in about 1 min. I'm wondering if there might be some sort of issue with Win7x64 Multi-core systems? None of the cores appear to be particularly taxed...even with other software running (Tbrid, Firefox, Downloder, etc.), CPU usage rarely hits 7% while DivFix++ is fixing a file. How can I further help troubleshoot this issue?
....forgot to also mention...that I've had this issue consistently for 3-4 months with many, many AVI files...both on a nearly "virgin" system and with a large assortment of various software installed and/or running.
Firstly this tool is not multi-threaded. I don't know why it's slow on your system too. I don't have time for debug on w'ndows yet. I am planning to release 0.35 beta, which has DivFix+2 Core that available at svn, that replaces core part completely. I think this will fix problems. There could be also "priority problem" that comes in my mind. At default, I remembered that set DivFix++ low priority for make other programs are not bottlenecked by my tool because of high HDD IO. I can investigate this when my homeworks are completed. :D
Installed 7 to VM and my laptop. I don't know when I test this problem. Because I cannot find time to start developing again. I am fully busy with wxHexEditor this month, But this summer, I believe there is time for start developing DivFix++ again. It comes my mind, you could compile DivFix++ via Visual Studio, I believe slowness because of old MingW compiler. Anyway, will try to solve this. I don't give up :)
Hi, I am back.
I am tested this bug in Win 7 x64 bit on QuadCore KVM (Virtual Machine) and it works as intended. No Slowness!.
Does this problem appears on every AVI file or on some AVIs?
Thanks for looking into this more. The slowness seems to be exhibited on every AVI file I try on two different Win7x64 systems. As a reminder, the same AVIs are very quickly fixed with vDub on the same systems. I don't know much about using virtual machine, but wonder if something is somehow different under that configuration. As you've mentioned before, I might be able to help further in two ways...trying v0.34 complied with VisualStudio or trying 0.35beta with the new core. I'd be happy to try either/both out on my machines and note any difference if you can prepare them for win7x64 and make them available to me.
I will test this on laptop but it has Dual Core, not Quad. I needed to detect why this is happening.
After inspection, will recover the app and might release new core's alpha. THere is no error messages writen to new code nor translations. So when this bug is fixed, will release new core.
Thanks.
(Un?)Fortunately DivFix++ v34 32Bit & 64Bit working good on Windows 7 x64 intel Core2Duo 2,5 GB Ram.
There is no freeze or lock up.
Fixed 600MB file under 32 seconds.
I used proper 600MB AVI XVID Encoded files which has no error in it. But I guess it will be same on broken/downloading files.
For investigating problem, could you test it with not-broken AVIs unde Windwos 7 x64?
Or this problem appears on broken files only...
Thanks.
Sorry for the slow reply. I did try running a few AVIs through DivFix++ that play without error in VLC. All of them seem to exhibit similar results...very slow processing with very little CPU usage. Here is typical message from DivFix++ v0.34:
Processing file : Test File.avi
Four CC is : XVID
Info: Original index chunk found at 728349874
Error detected at byte: 733690554
File end reached.
DMLH found: 125172
New Stream Size : 728339626
Total Error Count : 1
Total Frame Count : 333792
Video Data Frames : 125172
Audio Data Frames : 208620
Running the "fixed" file again thru DivFix++:
Processing file : DivFix++.Test File.avi
Four CC is : XVID
Info: Original index chunk found at 728349874
Error detected at byte: 733690554
File end reached.
DMLH found: 125172
New Stream Size : 728339626
Total Error Count : 1
Total Frame Count : 333792
Video Data Frames : 125172
Audio Data Frames : 208620
All 3 files (original, fixed and twice processed file) are 716,496 kb.
As I was running these tests, I wondered if the codecs installed on my computer has any particular effect.
In Virtual Machine (with 4 core) and on Real Core2Duo cpu but I cannot reproduce error.
I think there is not much to do.
As you well know, you cannot fix thing if it's already working.
I will compile special version with profiling support and will send to you.
Run with it and than we can see which function waiting/consuming too much time.
Perhaps, this could help