Normally the videos they edit are 10 minutes long. Last week they started this group that is 40 minutes long or longer. I believe that is why it started last week.

We have not installed any Windows Updates recently and AutoUpdate is off.

**Normally the videos they edit are 10 minutes long. Last week they started this group that is 40 minutes long or longer. I believe that is why it started last week.**

This might be a silly question, but do you have some good fans on those CPUs?
Monitor your core temps during the same renders, and see if there is any correlation between the temps and the point of render failure.

Suggestion #2: Do a system restore to a point before the V8 install instead of just reinstalling V7. Do you still have the same problem?

BTW, that file extension bug is a MainConcept problem, not Sony's, and they are working to get it fixed in the next update. If you've got lots of files to rename to .vob, there are some free batch renamers that will do the trick with a minimum of angst.

Try going back to Vegas 7d to finish your current projects. In the future, use tape rated for HDV and you should be able to use the latest versions of Vegas 7 or 8.

I'm sure that there will be some disagreement here, but here is my estimate of what your problem is:

Between Vegas 7d and 7e, Sony changed the way it handles HDV mpeg 2 clips. The good news is that since that change, HDV clips preview much more efficiently on the Vegas timeline. The bad news is that even the smallest data errors within the HDV clips will cause Vegas to crash. Tapes rated for regular SD DV recording tend to have these errors, but this has only been noticed since Vegas started tweaking its mpeg2 handling efficiency. By the WMP also seems to have problems with the same clips so it is not all Vegas's fault.

Going back to Vegas 7d will probably stop your crashing problems, but you'll also be back to the less efficient previews. None the less, it will get you through your current project renders.

What you will probably notice in 7e or 8, is that there are certain clips that are causing you problems. One thing you can do is to open the clips that are causing Vegas crashes with MPEG VCR (available from womble.com) and resave them. This will not rerender the video, but it will change the header within the clip and cause Vegas to treat those offending clips in the older less efficient but less crash prone method.

In the future you can probably get rid of most if not all of these problems by changing from regular DV tape to tape rated for HDV.

Just my two cents. I'm sure others will disagree.

If these issues only started last week why would you think the problem is Vegas? If you have not changed all these computers in some way then it might be related to your going back to version 7.

Totally remove version 7 and 8 and all traces of them. Remove old directories and Sony set-up directories, remove media manager etc, clean your registry and perform good house-keeping. Then reinstall Vegas 7 afresh.

I don't necessarily think Vegas is the problem, but nothing else on that computer is having an issue. It only occurred last week, I think, because of the length of the videos. They can still do their 10 minute videos without a problem.

The Video Cameras we use are not HD. The don't record to tape, they record to Mini-Discs.

It seems to me that if you have clerical staff using 5 dual quad core Xeon machines withtheir RAM maxed out to edit SD footage off of mini-disc cameras then you're throwing good money after bad. Have you considered just getting a couple of decent DV cameras or maybe transcoding all that SD mpeg to a more editable format?

Rob Mack

It is a DV camera, just not HD. Maybe I just don't understand the jargon...


Here's a thought. While working on trying to fix it, I found that some of the source videos were located on the local computer and some on the network. Would that have an effect?

Yes. It could affect it. What type of network do you have between the host computer and the server? You would want a gigabit connection between them if you do not have one.

As for the jargon, DV is avi and miniDVD is mpeg. They use two completely different codecs and DV is a lot more editor friendly.

j razz

The locations on the network could have changed.
An "L" drive could now be a "K" drive for instance.

Could be a problem, certainly you want to eliminate anything you have doubts about. Generally, while gigabit ethernet has the throughput to edit heavily compressed media (and your MPEG media is certainly that), ethernet isn't designed to give you all the bandwidth you need at all times, at least not unless you take special measures to set it up for this. Basically, there's just no guarantee.

DV (as opposed to digital video) is a well defined format for standard definition. It is definitely not MPEG, and the mpeg nature of your footage is probably the problem, which is why I suggest transcoding it to something else. If you had the disk space I'd suggest Cineform, SonyYUV or Huffman because these have better color sampling than DV. Other people may have better ideas on that. Transcoding MPEG to DV is likely to degrade your footage if you're working in NTSC.

Generally, mini-disc and hard disk recorders are recording some form of mpeg and not DV.

Anyway it's water under the bridge. You go to edit with the media you have, etc, etc. The first things I'd try would be to bring the media local to the edit stations, the second might be to reduce the preview RAM setting in Vegas to something modest, probaby between 16 MB and 256 MB but generally 16 at render time, and you could possibly fiddle with the render threads setting, reducing it to one or two. Try things and run tests. Luckily, you've got 5 machines so you can run several tests at once. Keep notes.

Other thoughts are that you might want to review the stills being used and convert them to PNG of the smallest neccessary dimensions. Tiffs use quicktime and that can cause trouble.

Generally, it sounds like memory troubles. Mpeg takes more RAM to work with, so do oversized stills. I don't think that Vegas is really managing memory the way it needs to to be stable. Vegas is a win32 application so it only gets to use 2 GB and you may just be running into problems.

Rob Mack

I was going to stay out of this, but I don't think anyone has put you on the right track, and I hate to see you spin your wheels or perhaps give up on Vegas and waste time on another editor.

I found out the hard way last month that Vegas can have VERY big problems with camcorder disc video. I corresponded extensively with tech support and was able to find a workaround.

Here are the details, which hopefully will help you.

When using a camcorder which records to disc, every time the camera is started, a new chapter is created. When 99 chapters have been created, the camera creates a new title. A client brought ten discs to me, one for each football game from this past season. The camera operator stopped the camera after each play. Thus, each disc had about 180 chapters, spread across two titles. I used the import function in Vegas 7.0d to bring these into Vegas.

Vegas proceeded to barf (technical term).

Here is a portion of my trouble report that I sent to Sony:

It transfers them fine when doing the import, but then completely freezes, due to thrashing, as soon as the SF* files begin building. I have tried building these just a few at a time, and that works until I get to about 15, and then things get unstable. I can switch to Task Manager, and I find that Vegas is doing hundreds of thousands of I/O writes in a very short period of time. What's more, when I try to switch back to Vegas after checking task manager, the thrashing becomes far worse.

Basically, the computer locked up.

I won't bore you with all the emails that went back and forth, or all the things I tried. However, before I give you the workaround, let me assure you that this is a Vegas problem, and not a problem with your computer or anything else that has been suggested. The reason not everyone experiences the problem is that it only happens when you have LOTS of chapters in an MPEG file, which results in hundreds of separate MPEG-2 files when you use the import function.

The solution? Well, rather than write something specific, let me simply copy the email that I sent to Sony tech support that described my workaround. Hopefully this will help you get through your projects and continue to use Vegas.

Here goes:

THANK YOU so much. You got me on the right track. In the time it took you to respond, I came up with a workflow that works perfectly and requires almost no time at all.

One last thing: Before you try the above workaround, I would suggest that you set RAM preview to zero (0) and also go to Options -> Preferences -> General and uncheck "Close media files when not the active application." This might solve the problem without having to use the above workaround (or some variation).

Ok, I copied all the videos to my computer. I rendered to 92% and then it crashed:

An error occurred during the operation. An Exception has occurred.

The details...



Sony Vegas 7.0
Version 7.0e (Build 216)
Exception 0xC0000005 (access violation) READ:0x24 IP:0x6A002E
In Module 'vegas70.exe' at Address 0x400000 + 0x2A002E
Thread: ProgMan ID=0x3E8 Stack=0x26CD000-0x26D0000
Registers:
EAX=44dbacf8 CS=001b EIP=006a002e EFLGS=00010202
EBX=0211b9b0 SS=0023 ESP=026cda50 EBP=00000041
ECX=00000000 DS=0023 ESI=44442878 FS=003b
EDX=44d8b418 ES=0023 EDI=019ed238 GS=0000
Bytes at CS:EIP:
006A002E: 8B 41 24 FF D0 85 C0 74 .A: 0B 83 C5 01 3B 6C 24 10 ....;l
Stack Dump:
026CDA50: 44DBACF8 43760000 + 165ACF8
026CDA54: 44D8B418 43760000 + 162B418
026CDA58: 01AAF8E0 019E0000 + CF8E0
026CDA5C: 44D8B418 43760000 + 162B418
026CDA60: 00000000
026CDA64: 8004E00A
026CDA68: 00000185
026CDA6C: 00000005
026CDA70: 00000003
026CDA74: 00000000
026CDA78: 019ED244 019E0000 + D244
026CDA7C: 0069E49E 00400000 + 29E49E (vegas70.exe)
026CDA80: 44D8B418 43760000 + 162B418
026CDA84: 026CDA98 025D0000 + FDA98
026CDA88: 44BDBD80 43760000 + 147BD80
026CDA8C: 44D8B418 43760000 + 162B418
> 026CDA9C: 006A6635 00400000 + 2A6635 (vegas70.exe)
026CDAA0: 44D8B418 43760000 + 162B418
026CDAA4: 026CDAFC 025D0000 + FDAFC
026CDAA8: 0000F900
026CDAAC: 022014D4 02100000 + 1014D4
> 026CDAD0: 004E258F 00400000 + E258F (vegas70.exe)
026CDAD4: 0000F900
026CDAD8: 00000000
026CDADC: 0000F900
026CDAE0: 00000000
> 026CDB28: 0057FA7D 00400000 + 17FA7D (vegas70.exe)
026CDB2C: 00000003
026CDB30: 026CDB40 025D0000 + FDB40
> 026CDB34: 33BC7BD5 33BB0000 + 17BD5 (mcplug.dll)
026CDB38: 00000000
> 026CDC20: 33BC35F0 33BB0000 + 135F0 (mcplug.dll)
> 026CDE14: 0A110000 0A070000 + A0000 (Decklink.dll)
026CDE18: 05B90000 05AF0000 + A0000
026CDE1C: FFD50000
026CDE20: F8C80000
026CDE24: F4C70000
> 026CDE40: 009F0000 00400000 + 5F0000 (vegas70.exe)
- - -
026CFFF0: 00000000
026CFFF4: 00519B40 00400000 + 119B40 (vegas70.exe)
026CFFF8: 00A80370 00400000 + 680370 (vegas70.exe)
026CFFFC: 00000000

This type of problem is related to your computer memory and how it is set up.

Run your virus checks. Run the FREE spybot Search and destroy and run the FREE House-call from TrendMicro.

Make sure you have your PAGE FILES and VIRTUAL MEMORY set right and for best Vegas performance.

Render to a dedicated HDD that has been been defraged and has a lot of free space - at least twice the final render size.

If you did the clean install as I described before and above there is very good chance your problem is gone.

BECAUSE THIS IS HAPPENING ON SEVERAL COMPUTERS IT INDICATES YOUR WINDOWS SETTING FOR MEMORY AND PAGE FILE OR A VIRUS (you said the computers were networked)

ALSO with many computers I'm wondering if your are LEGAL? Have you the same Vegas licence on all your computers?

Yep. we're legal. We have 9 total licenses. :)

What is the best Page Files and Virtual Memory for Vegas? How do I find/determine that?

Are you network rendering? If so try to use just one machine and if not try it. With Vegas on all your machines network rendering should be your option. If you are network rendering maybe you have a network interuption? Are you ethernet or wireless?

Did you try my suggestions?

Network rendering worked on one computer as a last resort. Trying on other computers just crashes.

John,

I haven't gone back to 7.0d yet. I wanted to render this on my computer, have it crash, and then call Support with that info. By the time I got all the files on my computer and got the crash, it was too late (considering my other duties here at work.)

I'm rendering now and if it fails, then I'll try 7.0d. If it succeeds, then I'm moving onto the net problem which is red screens whenever I view the whole project. I feel bad for our clerical staff... nothing but crashes all day. They have moved onto the smaller 10 minute projects and aren't having a problem.

When our camera operators send us the disc, they extract the videos as MPG files using Picture Package and that's what our editors received and work with. Each MPG is a sole clip (camera on, camera off) and there are no chapters.

The did set the RAM preview to zero and set those things to be off-- they usually are off.

I set the Pagefile to the Windows recommended settings.

Odd, my current render is estimated at 2 hours and 25 minutes while the video is only 38 minutes long. Usually it's 1 to 1 and would take 38 minutes to complete.

dump your cameras and go for either dv or hdv. i don't know of any serious enterprise that shoots (domestic) mpeg as source - your finished product will look much better as well...

leslie

I have discovered that these crashes are related to the use of Quad Core computers using Vegas. There is a significant thread discussion in this forum related to my problems with the same exception crashes as you're having.

Version Pro 8.0b MUST HAVE FULL QUAD CORE SUPPORT.

Darren Powell
Sydney Australia

Each MPG is a sole clip (camera on, camera off) and there are no chapters.

I probably gave you too much information in my first post. The problem I am describing is that Vegas chokes when fed large numbers of MPEG-2 files. It has nothing to do with chapters or anything else. You have large numbers of MPEG-2 files (in your larger projects). Therefore, I am pretty certain this is the cause of your problem.

The solution is to combine all the MPEG-2 files into one file (I used Womble, but since you have Vegas 8.0a, you could use that, I think). Then, edit from that single MPEG-2 file. Try it, and I think you will solve your problem. Also, if you have large numbers of hi-res JPEG files, you can end up with a similar problem (I mention that, even though you didn't say anything about still photos, just in case ...).

Combining everything into one video would be a problem. First, the editors would not know how to do that and it would increase their workload. Second, that's one big file. I'm talking 144 MPG's at 5.85 GB and 2+ hours of footage.

I figured it was the large number too or at least the sheer volume that caused memory issues. What's odd is at home on a much older, slower, less-powerful computer, I've edited longer more complicated projects without a problem.

As for the Quad-Core issues, that's interesting. When I rendered initially, I saw three of the eight processors being used heavily and the other five not so much. This was around a forty minute render. Then on my last render, I saw all eight being used heavily and it completed but it took two and a half hours.