I'm "track-happy".

I will regularly have projects with 10 video tracks or more and easily 10 audio tracks too. I'm crazy about the plugins too,...I use tons of them. On projects with 3 or 4 tracks with just a few audio,...I never hava a problem. I always assemble and preview perfect and can render to whatever I feel like. I do DV, HDV and AVCHD.

That "big" stuff, like I mentioned, always assembles fine it just gets tricky on the rendering. I start off with;

Quad + 3 threads.- if crash,
Quad + 2 threads - if crash,
Kill Quad in BIOS and render with dual + 2 threads - if crash,
Dual + 1 thread. = Never crashed yet. (not even on 3 day long renders.)

I'm running XP 32 bit - 3 gigs RAM.

BTW,...I assemble ALL my projects with Quad "on" and 4 threads set in config.

I would expect assembly and preview to be FAR more intensive than rendering....because if the "real-time" streaming nature of it. but nope,...never crashed there even on the largest projects.

I am using Vegas 8B more than 8C lately. For me it renders far better than C (on the same hardware)

I'm not worried,...I Sicerely believe it's a threading problem and I know SCS will nail it down.

For Serina,...unless it's an interupt request (IRQ) problem with the hardware/video driver, I dont think a video board affects Vegas rendering. Vegas doesn't thread out processing to any video card GPU. (cards matter nothing in that respect)

I am glad though that you are not going through the issues that many of us are.

CT

"I'm not worried,...I Sicerely believe it's a threading problem and I know SCS will nail it down."

Well, far be it for me to outright tell you you're wrong. You could be as right... or as wrong as I. Only the SCS Engineers would know.

Avchd is a different ball game. It's crashy for me when rendering 1920x1080, but I don't think it's an SCS issue anywhere near as much as it's just plain avchd. Even the PP folk are crashing with the stuff.

Regardless to whether or not Serina's card is an IRQ issue... it is affecting her editing... and it's another example of how sensitive hardware changes can be.

I remember overclocking a P4 once. I got it stupidly high at one point and had no issues. Then a few weeks later it started acting up. From this point it would only run oc-ed at 10% and it took me the longest time to figure out why. One of the usb cables that I had just started using for my printer had a small nick in the outer casing. Was it stray capacitance or electro-magnetic energy from a nearby AC cable entering the casing? Who knows but when I changed it out all was normal again.

At any rate... enough said.... I've grown tired of this thread.... I think you're for sure right about one thing... what ever it is SCS will fix it.

>> shutting down a few cores will keep Vegas from tripping over
>> itself. It seems to work in some cases, but that does not say
>> that it is directly a quad core issue

It does not. It identifies it as an SCS issue that comes to light mostly on Quad Core computers. It means that the problem is most likely related to an internal Vegas resource that is not properly synchronized (read about semaphores etc if you want to learn more). The fact that the problem is intermittent and doesn't show up on some systems but is consistent on other systems is yet another indication of this. There is another strong indicator that the problem is entirely Vegas, and that is the fact that it has not been reported on 8.1. Given that resource allocation is what is mostly addressed in a port from 32 to 64 bits, this would be an indication that the issue has more or less accidentally been resolved in the 64 bit code base.

This is the interesting thing about this particular bug, all reports and all work-around suggestions from SCS points to one single culprit: Vegas.

>> crashing is more than likely a hardware/software conflict

Actually, this is unlikely. There are some times, the video card example was one such, when hardware comes into play. In fact, it is usually not hardware but accompanying software, the so-called drivers for said hardware. Hardware/driver problems usually come to light very fast and are easily identified, particularly since they tend to have rather dramatic effects (BSOD).

Software crashes come in many variations, but the vast majority of software crashes have a tiny amount of common problems. By far the most common is improper use and handling of shared resources. When moving to multi-core and multi-CPU systems improper handling of resources is going to become more common since there is a higher chance that code accesses said resources in parallel than with single-core systems.

Now, back to what you said

>> the crashing is more than likely a hardware/software conflict

This is in fact hardly ever the case, and the chances that this is the cause of the rendering problems observed with quad core systems is as close to zero as you can get. Let me elaborate.

Resource allocation problems usually have two outcomes that are not beneficial for the end user. The former is that the output of the computations involved are incorrect. The well-documented black frame problem would be one such. The software assumptions leads to bad calculations and the result is compromised. The second most common result of a resource allocation problem is that the internal state of a piece of software is compromised and shortly after the software it self will crash.

The problem you are describing usually ends up slightly differently. One of the errors are in common though. Output from computations might be compromised by bad hardware or drivers. VIA had some FireWire cards and chips with either bad firmware or drivers that exhibited this problem. You simply could not rely on them for capture. If you have crashes when there is a HW/SW conflict it usually doesn't result in (only) the piece of software you are using crashing however. HW/SW conflicts typically shows up as system crashes. BSODs if you wish.

So, if someone says: My computer crashes when Vegas renders, you can assume that 100% of the time that is a problem with the users hardware or the users drivers. Vegas should not be able to crash Windows even if it tried its best. Well, maybe not 100% of the time. Perhaps Vegas could expose Windows problems in 0.1% of the cases where this happens. Please note, this is not the case for real-mode operating systems like Windows 3.x/95/98/ME where a piece of software could indeed garble the internal state of an operating system. In such cases a computer crash could be caused by user software. This is not the case for any modern operating system.

If someone says: Vegas crashes when I do this or that, you can assume it is a Vegas problem at least 98% of the time. If the crash is silent, that is no error message, or it is accompanied by one of those "performed an illegal operation" error messages, you can probably increase that by almost two percentage points.

This is a problem you have blink. You assume a lot of things based on zero knowledge. Your statement about HW/SW conflicts prove this beyond any doubt whatsoever. Any software engineer will be able to explain this to you. I have been on, or directed teams of software developers for 20 years. HW/SW conflicts is so little of an issue for a software development team that the only teams that seriously take them into consideration are teams working on embedded software since they do in fact have full access to the hardware.

>> I don't think it's an SCS issue anywhere near as much as
>> it's just plain avchd

And yet another proof. Sorry blink, but here you just show how you claim things with gusto, and you are 100% dead wrong. AVCHD is data. Data can not possibly crash anything at all. Data doesn't execute, and only execution can crash software. If Vegas and PP crashes with AVCHD data that means that Vegas and PP have problems in the Vegas and PP code, not that there is any problem with AVCHD. There is not even a theoretical possibility that AVCHD can crash anything.

Why are both Vegas and PP having problems? Two possible reasons. They might both be using the same piece of third-party software and this software has a bug. Not unlikely, but even more likely, both teams have worked on the AVC code they them selves have written for far shorter a time than on the rest of their stuff. Newer code has more bugs than older code for this reason.

If these crashes are more prevalent with AVC than with other data that would be just yet another proof that this is a Vegas problem and not a HW/SW problem.

Terje and Blink, although you've both got plenty to say,whenever I see a post by either of you these days I just skip by it, because I know that there's a good chance it will contain some valueless ego baiting comments between the two of you.

For your own sakes, as well as the forum's, please move on.

YAWN........ blah blah blah, I say let's vote Terje off the island but Blink gets immunity.