View Full Version : xvid 1.0.1 instabilities
tormento
12th July 2004, 16:23
Hi!
I had some problems originally I thought were caused from Avisynth or Dgindex decoding dll.
After some trial and error test I have found that the murderer of my VirtualDubMod instances is Xvid 1.0.1.
Using Xvid 1.0 or Javor's unofficial solve problems.
Anybody else has found the same strange bug?
Koepi
12th July 2004, 16:32
If you have stability issues with my builds you seriously should check your hardware.
XviD - especially when built with such optimizations that I use - stresses hardware so much that it will easily fall over issues you won't find in a 6 hour memtest run.
So make sure your CPU has a temperature in reasonable range, that you don't o/c your system,...
This helped a lot of people which were reporting "stability issues with xvid". You might wanna get used to the search function of this board.
tormento
12th July 2004, 18:31
Originally posted by Koepi
If you have stability issues with my builds you seriously should check your hardware. Thank you for your kindness.
I have a water cooled PC (P4@3.4), with a full load temperature of ~41 celsius. My rig is absolutely stable with xvid 1.0 and unofficial Javor's build. The only program that crash is Virtual Dub Mod and only when compressing with Xvid 1.0.1. I run Ray Tracing and Finite Element Analysis for hours, sometimes even day without a hiccup.
Please believe me, I don't have any reason to make a false report. I adore Xvid and this post is only to help community and not to start stupid flames.
P.S: I repeat: absolutely stable with xvid 1.0 and Javor's. Same sources, same avs.
P.P.S: I have seen a similar report from Soulhunter but it has been solved.
Andrey
12th July 2004, 21:38
To: tormento
One question.
Do your VDub crashes at the end of encoding or at the middle ?
And if it crashes at the end, do you use VDub's Job control or run encode imidiately ?
I have some problems with Job control and latest buld - it complete all encoding and then crashes(I mean simply dissapear, when I open it again, Job control show aborted status, but encode itself is fine)
tormento
12th July 2004, 23:30
Originally posted by Andrey
To: tormento
Do your VDub crashes at the end of encoding or at the middle ?
Randomly.
It simply disappear, first pass, second pass, doesn't matter.
Koepi
13th July 2004, 06:16
Simply disappear = usually memory problems. (Yes, I know you think your machine is safe. it's not.)
Andrey
13th July 2004, 06:49
Simply disappear = usually memory problems.
Yeah, I guess. :mad:
But still can not locate the problem - my machine is new (buy it at the end of May, Celeron 2.6, so it can have a bit incompartible memory easy).
If I have a bit more time, I will try one of the previous XVid builds (RC1 for example) to check, if problem still exists...
I switched to 1.0 just after I buy a new machine, so I can not tell, if it depends on machine or on build.
But strange anyway, when I run encode manually, all works fine...
tormento
13th July 2004, 07:36
If I have a bit more time, I will try one of the previous XVid builds (RC1 for example) to check, if problem still exists...
I have tried to use job control in VDubMod. I do have the same problem with the last job queued, even with Javor's build. However it aborts not at the end but in a random spot.
When I use manual encoding, no problems at all, even after 7-8 consecutive encodings. Using jobs, hangs at the least, even after only 2-3 jobs.
Strange enough. I hope someone more clever than me (Soulhunter?) had the same problem and tries to reproduce it.
Koepi
13th July 2004, 08:12
Another note: you're sure to use vdubmod 1.5.4.1 or older version?
Because it's a known bug with newer vdub(mod) build, and you find it in the FAQ...
tormento
13th July 2004, 09:36
Originally posted by Koepi
Another note: you're sure to use vdubmod 1.5.4.1 or older version?
Because it's a known bug with newer vdub(mod) build, and you find it in the FAQ...
Sorry, no. :eek:
I am using the Gordian Knot package and it includes 1.5.10.1. Didn't even noticed that it was flawed, usually GK includest the latest stable versions.
I'll try 1.5.4.1 and tell you.
Thanks. :rolleyes:
Andrey
13th July 2004, 17:59
I am using the Gordian Knot package
Sh%t. The same here...
Just downloaded lates GK too some times ago.
Sorry for wasted your time, Koepi.
Soulhunter
13th July 2004, 18:49
Originally posted by tormento
I have seen a similar report from Soulhunter but it has been solved. IIRC, caused through some fu in the registry !!!
Bye
tormento
13th July 2004, 21:27
Originally posted by Soulhunter
IIRC, caused through some fu in the registry !!!
Thank you for your interest in this topic.
I have read every reply to my question, however nobody has yet told me why 1.0.1 crashes and 1.0 (or Javor's) does not.
Koepi, have you changed some optimization flags between the two compiles?
Koepi
14th July 2004, 06:35
tormento:
try clocking your system at it's original specs and see if it's still crashing for you please.
tormento
14th July 2004, 09:44
Originally posted by Koepi
tormento:
try clocking your system at it's original specs and see if it's still crashing for you please.
My system is at default speed. I use watercooling to have a quiet system, not for overclocking. :p
Boulder
14th July 2004, 09:48
Try running Prime95 for 24 hours or so. The blend test will tell you whether it's the hardware or not, I've seen some rock-solid machines go down after 20 hours of continuous testing:D
Koepi
14th July 2004, 10:17
I've seen rock solid machines going down after less than 1 hour encoding with my binaries ;) Where other programs need 20 hours, xvid will tell if your cooling system, o/c'ing, memory works flawless in a few minutes. *hide*
Regards
Koepi
Boulder
14th July 2004, 10:23
Well, I just thought that he should try with some other program since v1.0 works and v1.0.1 doesn't. Usually Prime95 will crash within an hour if there's something wrong:p
Soulhunter
14th July 2004, 21:53
Originally posted by tormento
Thank you for your interest in this topic...
Deleting all XviD related files n' registry stuff (by hand) could help... ;)
Bye
Ptit-Louis
19th July 2004, 18:40
Hello
I had the same problem (virtual dub error, virtual dub disappear or system freeze) only since 1.0 final. It is RAM problem I think (I had the same problem with CCE and MPEG2 and not with xvid at the same time). Since I actived the "turbo" mode, I have no problem (4 DVD personnal copy without crash): maybe the RAM is less sollicited with this option checked, or maybe it's just a coincidence with my computer.
I hope with this will help you
margen
20th July 2004, 13:07
Hello,
I've had the same problem since I started using v 1.0.1. I do believe that I have a rock stable machine. I've been testing it several times with Prime95 blend test for 2-3 days without getting any errors whatsoever. I'm also using a newer VDMod build - 1.5.10.1 so I'm going to have to see how it works with older version. I've been using Koepi's XviD build for some time now and I never had a problem with it prior v 1.0.1.
Didée
20th July 2004, 13:49
Welcome to our nice little place, margen!
There was quite some discussion lately, regarding "stability" of Koepi's 1.0.1 build.
Personally, I have no problems at all with this build, and I'm encoding all days with it. However, my encoding machine didn't crash once in over two years now. Not one single time, except for power breakdown from thunder'n'lightning. Hand-picked components, see ... ;)
You definetly should try to step back to Vdub v.1.5.4. This one is mostly labelled as "trusted". v1.5.10 has some little buglets and is not considerd exactly "rock stable".
(Personally, I don't even fully trust 1.5.4 ... for running job queues, I'm still using v1.4.13 in 99% of all cases.)
If this doesn't solve your problem, try another 1.0.1 build. E.g. the build from virus (http://www.webalice.it/riccardo.stievano/video_stuff/xvidvfw101-log.zip) is nice, as it enables logging capabilities. You won't mind 0.5% slower encoding too much, will you? ;)
- Didée
Originally posted by Didée
... Vdub v.1.5.4. This one is mostly labelled as "trusted". v1.5.10 has some little buglets and is not considerd exactly "rock stable".yep .. vdm 1.5.10 is an unstable stuff, definitely. (& 1.5.4. is also that) however i use it for awhile wout any problem. after some occasional crash i 'distilled' a simple rule; vdm must be always on the top. simply, keep it 'maximize' only if u work with it, otherwise keep minimized. batch operations are also 'stable' if run minimized. keeping this in mind, i'm happy with it. (but when forgetting ... :-/ )
just my experience .. dunno whether helps or not
the bests
y
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.