What I find curious is that you only have the problem rendering, not playing the project back. The only difference is when rendering the CPU can be at 100% for a long period of time. Are you certain it ain't cookin?

You wouldn't be the first to have renders fail due to a furball on the CPU.

Bob.

Well there are additional weirdnesses...

... when/if it completes the render (and then crashes), it dies after handing back to the
main Vegas GUI. It *always* crashes after rendering, but on occasion in the last 24 hours I've managed to move the cursor on the time line before it dies. If I just go off to do something else productive whilst it's rendering it's always crashed by the time I get back - being able to interact with the GUI only works for a few seconds immediately after the rendering completes.

I'm back to square one again now: the attempt to render audio and video separately then bring them back together failed. The output was truncated.

Sigh.

And yes, I will check the CPU cooling. I'm very careful usually to ensure it is well cooled - heat transfer paste carefully (note, not excessively) applied, etc., and careful routing of ribbon cables so that they don't obstruct the airflow. I very much doubt that's the problem though.

What I find curious is that you only have the problem rendering, not playing the project back. The only difference is when rendering the CPU can be at 100% for a long period of time.Bob, I don't think that's true. Rendering is quite a different operation, and over the years, Vegas has exhibited many problems when rendering, most notably when rendering high-res photos. They would playback just fine, but when rendering, the computer would hang.

I am guessing that the key to finding a workaround will be making sure that nothing else (i.e., no other program) is consuming memory behind the scenes on his computer. The preview RAM setting is important. And, if there are photos, or third party fX, I would suspect those as well.

But to the point: what happens during playback and what happens during rendering are quite different because of how memory is used.

blink3times

"I stopped scene splitting on the fly. I now capture a tape in its entirety and then do the scene splitting AFTER the capture (HDVsplit has an option to scene split a file on the HDD). Ever since I started doing this the crashing has just COMPLETELY vanished.... and I used to crash at least 25 times during one render (no joke!)."


In a similar manner for both HDV and SD projects I do a rough edit by manually capturing chunks of .3 to 1GB of data to clips using Vegas standard capture functions. I then use the trimmer to select the parts I want and drag to the time line. No problems when you work this way.

There are a sizeable number of Vegas users who do not have problems using Vegas so the software itself does not have major stability problems.

"Multiple posts aside it is NOT the responsibility of the customer to solve any problem with the product. The product is the responsibility of the product manufacturer and it is their sole responsiblity to fix it."


I doubt that you will find no-name or home built computers being used by Sony for development or testing of Vegas. As with most corporations they use computers from mainline manufacturers simply because they represent a more reliable platform. A microcomputer is one of the most complex devices you can buy. Video editing software pushes the microcomputer to the max limits.

There is no way a software manufacturer can predict how software will react on a "mix & match" home built set engineered by hearsay on forums and picked from a catalog!

Vegas and other software often get an undeserved bash for problems it has no control over. The user must take some responsibility to buy adequate and reliable hardware that is capable of the stress of video editing.

Look at the brands major corporations buy... that's where to start.

Vegas has some minor problems but instability and crashes are not happening for many users.

There is no way a software manufacturer can predict how software will react on a "mix & match" home built set engineered by hearsay on forums and picked from a catalog! I have to disagree with this. While it is definitely true that computers built at home are often set with the wrong BIOS settings, or are overclocked, I can tell you from personal experience that computers from Dell and HP include an ENORMOUS amount of "free" software, much of which have "helper" or "startup" processes which run in the background. Some of these cause problems, and I have documented these in the past with the HP printer process that monitors the card reader present in some HP printers.

Also, the BIOS and DMA settings from some major manufacturers are completely screwed up. In some cases this is done to avoid having any sorts of conflicts. Again, I have documented cases where the disk DMA was intentionally turned off in computers shipped from major manufacturers, and was instead set to the MUCH lower PIO mode in order to avoid any potential conflicts. Problem is, this absolutely ensures that if the computer is used to capture DV video via Firewire, that the computer will drop frames.

Finally, it is my experience that many medium-sized and also small corporations (I don't do any work with F500 companies) actually prefer purchasing computers from local computer dealers because they can get local service from people they know rather than deal with the 3rd-party service that is generally what you get when you purchase an on-site service contract from Dell or HP.

The main problem -- and this is always at the center of any Apple vs. IBM discussion -- is that Apple is a closed architecture and therefore has far fewer of these problems, whereas the "IBM" architecture actually hasn't been controlled by any company almost since the first IBM PC shipped in 1981, and therefore the idea of what is the "correct" configuration simply does not exist.

"There are a sizeable number of Vegas users who do not have problems using Vegas so the software itself does not have major stability problems."

I think you're right. The software itself has not crashed on me once.

I'm frustrated, as it works really well. As a longstanding (10+ years) Sound Forge user, I'm used to the GUI approach (and I like it), and Vegas' editing interface so far has been brilliant. I really like it to work in. OK, there are niggles (why, for example, is 'mute all' on the Options menu!?!), but they are trivial. My previous nonlinear experience has been Mac + Media 100 and a hardware-intensive early Avid clone on the PC (can't remember the name). The Media 100 system was brilliant for its time, but way too easy to slip sync by accident. Vegas' grouping of clips, sorry, 'events' is intuitive and really fast - I just wish I didn't have to use a 3rd party tool to grab tracks 3+4 from the camera.

I really like Vegas, but it just hasn't been stable whilst rendering.

- - -

I'm going to have one more try at a complete re-install to see what happens.

I did this before without major improvement, but I also did a major virus scan when trying to fix this problem, which removed some questionable Java applets (well, I seriously doubt they had any bearing on it but anyway) and I've just downloaded a QuickTime update, in case. So far nothing has improved - if anything it's crashing earlier in the process, so it's worth a try.

The other reason (thinking around the problem) is that I've a 'half-installation,' in that I chose not to install DVD Architect. It's possible that it overwrites a DLL or something similar, such that the problem goes away when both are installed. This isn't as daft as it might appear, in that one repeatable crash definitely happens on the close of the renderer child process, returning to the Vegas GUI. If there's a shared component that's iffy, it might be overwritten.

Obviously it's speculation. I just don't know, but I will remove Vegas, and re-install it, together with DVD Architect this time, and see what happens. . .

johnmeyer

Agreed on all points. My experience is with F500 companies and many format and install a mirror image of the op sys and software and configurations inhouse for their own purpose on each new machine. For the individual, you must choose not to install extra provided software or disable or delete it otherwise.

How can a homebuilder even know if the MB he bought is a reject or a rejected design from a major (or minor) manufacturer?

"whereas the "IBM" architecture actually hasn't been controlled by any company almost since the first IBM PC shipped in 1981, and therefore the idea of what is the "correct" configuration simply does not exist"

... which is exactly why the major manufacturer has the advantage of resources to engineer a workable system.

My point is that Sony Vegas should not bear the blame for problems which are not being universally experienced by all users.

y point is that Sony Vegas should not bear the blame for problems which are not being universally experienced by all users. Agreed.

The other reason (thinking around the problem) is that I've a 'half-installation,' in that I chose not to install DVD Architect.I recommend you install DVDA. I don't know if it will change the stability of the renders, but it definitely installs the DLLs needed for MPEG-2 render and this may in turn affect properties of HDV or possibly even AVCHD, although this last idea is pure speculation on my part.

The main problem -- and this is always at the center of any Apple vs. IBM discussion -- is that Apple is a closed architecture and therefore has far fewer of these problems, whereas the "IBM" architecture actually hasn't been controlled by any company almost since the first IBM PC shipped in 1981, and therefore the idea of what is the "correct" configuration simply does not exist.


It's an interesting point you raise. I used to work for a Fortune 500 PC manufacturer, in peripherals. There are standards, but, as you say, the rush to market often causes all sorts of corners to be cut.

SCSI used to be my field, and I well know the fudge factors employed to get bus timings etc to work out correctly. there was a lot of stuff out there that simply didn't conform to the standards, but the other problem was that standards ratification lagged behind the market way too much, so that draft standards had to be used, with the risk that late changes would render existing products non-compliant.

My guess is that a DV camera on the Firewire bus is designed to look like a tape drive ("sequential access device"). Firewire is SCSI, after all, and tape drives are very complex things to control, compared to, say, hard disks.

There are (or there were) PC standards though, driven mainly by Intel and MS, which software vendors used for testing: <http://www.microsoft.com/whdc/archive/pcguides.mspx>

When I was involved in the process, these were very important to us, but if 2002 is the latest on the MS web site, I guess they've given up now.

I recommend you install DVDA. I don't know if it will change the stability of the renders, but it definitely installs the DLLs needed for MPEG-2 render and this may in turn affect properties of HDV or possibly even AVCHD, although this last idea is pure speculation on my part.


John, you seem to be right!!!

So far, it's stable.

I have rendered out the project and control returned to the GUI without a crash (I think that's the first time it's happened). The other thing is that, for the first time, I was able to convert from 720x576 (non-square PAL DV pixels at 1.096 approx) to 768x576 (4:3 square pixels), which is necessary to minimize motion artifacts on YouTube. Previously it was simply refusing to do this, even though the settings were correct.

I'm holding my breath through every render at the moment, but it's looking promising. . .

Hey, congrats if you are getting renders to work!!

I'll have to file away this solution of recommending that DVDA be installed.

Also, thank you for posting back here that -- at least so far -- things are working. Many times people don't do that, or in my case, berate me for being an idiot, something to which I will readily admit, but don't like to be reminded.

As to SCSI, I spent a LOT of money on that over the years, especially on cables. I always felt gypped, however, especially when I couldn't tell any difference between the "new" IDE drives (late 1990s) and the SCSI hard drive I had been using. I was so caught up in SCSI that all my CD-ROM drives from 1991 until almost 2000 were SCSI, as were my scanners.

I don't miss it in any way. In addition to being expensive, it slowed boot times, and the terminations always caused problems for me.

I say: RIP SCSI.

I think the big point here is that... Sony needs to start owning up.
I too have posted my problems on this forum over the last release of DVDA 5.0.
I spent two weeks talking with programers about the rendering problems I encountered. Having to explain in detail almost every time I got a reply back from sony, over and over. Sending in sample after sample.
In the end, they didn't even admit that there is a problem, instead gave me a work around solution to my problem.
I got more help from people in this forum.
Some people (TheHappyfriar) not so much!

I agree sony has some catching up to do to keep their image clean and to remain a contender to those already established.

As to SCSI, I spent a LOT of money on that over the years, especially on cables. I always felt gypped, however, especially when I couldn't tell any difference between the "new" IDE drives (late 1990s) and the SCSI hard drive I had been using. I was so caught up in SCSI that all my CD-ROM drives from 1991 until almost 2000 were SCSI, as were my scanners.



To be honest, I think it was a solution to a problem that didn't exist, at least in the desktop PC world.

I started working with it in the early 1990s after I left broadcasting. Most of the development engineers had come out of a minicomputer environment, and there were still disk controllers around in the PC market that low-level formatted (remember having to find the hidden disk BIOS entry point with EDLIN to kick off the formatter?). There were other 8-bit bus solutions around (HP-IB springs to mind), used for peripherals, but there were speed limitations that SCSI was intended to address. Your slow boot was the host having to check 7 or 15 addresses for devices (and wait for a timeout in each case), and probably complicated by on-board disk BIOS extensions with their own timeouts (not exactly a SCSI issue but still really slow and annoying). That boot thing was OK for a mini that got turned off perhaps once every six months, but stupid on a PC!

SCSI just got too all-embracing and far too complicated. SCSI-2 was still a draft standard well into the days of SCSI-3 disks. Amusingly, if you thought SCSI-3 parallel cables were expensive (the 68-way ones), had we stuck with SCSI-2, per the standard you'd have had TWO cables going to the devices, one 50-way and one 68-way (carrying 8-bits of data each!). There was even 32-bit in the spec (two cables), but nobody was quite that crazy!

SCSI may have been the evil child of minicomputers (Apple's implementation was always non-standard), but it left a good legacy: ATA, SATA, Firewire, Fibre Channel storage, and to a lesser extent USB all use protocols derived from SCSI-2. AFAIK, Firewire (IEEE1398) still is SCSI - it's certainly part of the SCSI-3 standards.

The idea of 'intelligent' peripherals was the Big Idea though. It would probably have happened anyway, but the market competition in SCSI gave manufacturers a lot of IP they could recycle, and our present storage etc. is much cheaper as a result. Amusingly, the old SCSI standard covered all sorts of stuff that was never - or hardy ever - implemented: SCSI printers (HP had some industrial ones, for big banks!), processor buses (no way!), serial SCSI (which mutated into SCSI-over-IP), and communications devices (SCSI modems). I have a SCSI floppy disk upstairs somewhere in a cupboard - they weren't just Apple, they were common on UNIX workstations too.

The big mistake (apart from eye-stretchingly expensive cabling) was assuming a shared parallel bus could keep up with bandwidth requirements. It couldn't, but nobody considered Moore's law in the early stages. The biggest performance hit is trying to have more than two devices-per-bus (the host being one of them), and/or combining electrically slow and fast devices on the same wire. Our present-day SATA stuff is effectively SCSI-3, but it runs like lighting because it's a two-device bus. AFAIK, the latest SATA protocols are just thinned-down SCSI-3.*

So it wasn't all bad, although looking back it was ill-applied to desktop PCs and it was very, seriously weird.

RIP from me too.

S.

*amended this slightly after checking the Wikipedia article. SATA is apparently defined as point-to-point (i.e. only two devices), which in itself eliminates the whole negotiation phase of the protocols, and would make it much faster. The command queuing in the latest version seems to be from SCSI-2!

Great post on SCSI. Thanks a bunch!