Your post reminds me of a problem I had with HDV files using an earlier version of Vegas. And it was while building the audio peaks.

What would happen is somewhere around 60-80% the process would seem to stall and the computer would seem to be locked up. If I tried to abort it, it would take some effort and then Windows would want to send an error report to Microsoft.

If I left it alone and let it go for a long time, it would eventually finish and unlock-up the computer and the file would then be loaded. However, if I were to zoom out of the timeline in the area where the problem is, at the right zoom level I would see red frames instead of what the video should be. That part of the video was corrupt.

If I then tried to scroll through that portion of the video then Vegas would lock-up real bad and crash big time.

My video was captured direct to to hard drive using the Focus Enhancements Firestore FS-4. So there were no tape dropout problems that could cause this corruption.

So basically the file had become corrupted somewhere between 60 - 80% of it for whatever reason. So I would carefully edit out that portion of it and use what I had from camera 2 in it's place.

How all this relates to the problem(s) that others are having with 7e I am not sure but in your case you may be getting some file corruption causing playback problems with your wmv files. If that is the case it would seem that flash would not solve it.

As for me, I quit using HDV with the Church services and am using widescreen SD AVI.

I still use HDV with the theater videos though because I can touch-up the framing a bit with Vegas.

I do have a problem with mysterious black frames. I would play the video on the timeline and see a split second of black on the preview but if I zoom all the way in on the timeline they are not there they would loom normal even though they were not. I could edit out 2 frames at that location and then it would quit.

With my old system those black frames would show in the rendered file. It was a nightmare having to litterally stare at the preview to watch for those black frames. With my new system they are still there but now it gets even more wierd because I can change the size of the preview window and sometimes they would show and other times they wouldn't. Also they would change locations on the video. The only good new is that they no longer show in the rendered file.

I do know that in my case the problems with the building of peaks was because of file corruption. For those who have problems with 7e, it may be the way the files are captured and what camera was used that causes Vegas 7e to trip over them so to speak.

Looks like the fix in 7e maybe didn't quite do the trick. Even so, I can't blame Sony because this is among the category of wierd problems that are difficult to solve.

I hope someone can make sense of all I just said and I hope it will help lead to a solution.

Why are you using Hdvsplit? Vegas can detect scenes. Or are you just wanting smaller files? That may be a source of at least part of the problems you are having.

Danny Fye
www.dannyfye.com
www.vidmus.com/scolvs

I use hdvsplit when Vegas has problems either capturing or detecting my FX1, which is fairly often.

I went back to 7.0d and tried it - it failed once again. After a few commands in Vegas it kicked to the desktop. I tested with the same results several times. I'm at a loss.

Because we're full-time now, I feel like I need to have a stable system. I can't imagine that it would take too long to learn FCP, and I can always use the PC as a (weak) backup.

I think the answer is in your previous reply when you said, "I use hdvsplit when Vegas has problems either capturing or detecting my FX1, which is fairly often."

If you are having problems capturing then the captured files will have problems and thus Vegas will have problems with them.

I think you may have already mentioned it but how long has it been since you have done a full and clean install of Windows XP?

Also, you may have a problem with the firewire card or whatever firewire port that is built in to the motherboard.

I know that the devices that I have such as the FS-4 HD's are very picky about which card I use.

One unit works great with card A and the other works great with card B.

I can get the unit that works great with card A to work most of the time in card B but the unit that works great in card B will not work at all in card A.

While this is with the FS-4 HD's it may also hold true with different camera. There are tolerances in all devices and if one is towards one end of the spectrum and the other is towards the other end then they will not work well if at all.

So I find it difficult to blame Vegas until you solve your capture problems first. Also, if there are other problems such as hardware and/or software conflicts then those can cause all kinds of problems as well.

If it works well for one, it should work well for all.

I can capture m2t from tape and have the scenes split properly and everything.

Now, if you go to the Mac, all the problems you are having may very well go away. Reasons would be a different firewire port that is more compatible with your cameras and/or no conflicts in hardware and/or software. Then again it may not and you still have the learning curve as well.

As a last ditch effort for Vegas and the PC, I would suggest you get get a different firewire card or one that can be used instead of what is built into the motherboard and do a test to see if that works or not. If not, get another hard drive that you can do a test re-install of Windows XP on and see if things work then.

You can't solve problem A while you have problem B that may be causing/contributing to problem A.

Danny Fye
www.dannyfye.com
www.vidmus.com/scolvs

>how long has it been since you have done a full and clean install of Windows XP?

It has only been a month.

I'm going to get a new capture card today -- good call. What you said also gave me an idea to try rendering on the laptop that I captured it on.

Thank you so much.

Something else I thought of. Uninstalling software doesn't necessarily unsinstal it. Make sense?

Problem is, uninstallers are typically poorly done and don't do a thorough job of uninstalling the software. They tend to leave temp and other folders behind as well as certain files and most important, junk in the registry that can recreate havoc when one re-installs the software.

So uninstalling Vegas 7e does not necessarily mean that all of the possible problems from it were eliminated.

All associated folders (temp or otherwise) and files would need to be removed and the registry would need to be cleaned in order to remove everything that may have caused the problems.

Question, was Vegas 7d working ok before you installed 7e? If so then you may have to do extra steps to make sure that 7e is 100% uninstalled even though you now have 7d installed. There can still be remnants of 7e there.

It's a bit like deleting files on a computer. They are not really deleted, they are simply marked for deletion. Ufortunately uninstalling software can (in shades of gray) be the same.

You still need to solve the capture problems one way or another.

Once you get everything in good working order, get the software called "Casper" and clone the system drive to two backup drives. So if anything happens in the future, you won't have to go through all of this mess again.

Danny Fye
www.dannyfye.com
www.vidmus.com/scolvs

The capture thing is a mystery. It makes me wonder if I should get a firestore instead of a Mac.

I tried it again, removed Vegas, cleared the temp files, cleared the Vegas folder, restarted, downloaded 7.0d, installed it, CRASH. I then tried it on my wimpy little laptop, and it worked!

Yeah, uninstalling doesn't always work properly. That's why I suggested just doing a clean install. It'll take 2 hours or so to get XP installed again, Vegas installed, updated, etc, etc, and then you'll be back up and running. :)

I'm all for troubleshooting, but not when you have deadlines (though I hate not knowing *why* in case the problem happens again).

I'd get a Firestore over a Mac. Have you seen all the OSX 10.4.9 problems posted on the forums? Granted, it's almost always the same problem (dropped frames when capturing), but it shows that Macs aren't perfect as they've been touted, and are open to random problems like any other platform/OS. Just because you have a Mac, doesn't mean you don't have problems. If you just have *one* problem right now, I would fix that, instead of switching platforms and maybe having 2 problems, which is 200% more problems than you have now. ;)

Just do a clean install and get on with your projects already. :) If you really want to, make a clone of the drive as it is now, and try to troubleshoot it later. But if you need to get moving on this, just backup anything on that drive you need to keep, then boot off the XP install disc and do a clean install.

Eric

I agree. Looks like the troubleshooting part is going to take way too long in this case.

Once she gets it working properly again then she needs to get a software call "Casper" http://www.fssdev.com/ and use two hard drives to clone the boot drive to.

I prefer two backup drives just for the extra insurance and to allow for staggered backups such as to drive one this week and drive two next week. So if anything bad shows up then at least one of the backup drives should hopefully have a backup without any problems.

Also, one should always make a backup before doing any updates to any software.

The biggest problem with both PC's and the Mac is not so much the systems but the software that gets put on them. It costs money, time and money to create software and too many times short-cuts are made such as file sharing among applications and so on that can cause serious problems later on.

Anyway, a clean install of Windows XP is needed in this case and then backup, backup and backup. Did I say backup?

Dana, sorry I couldn't help you more with the troubleshooting part. Hopefully after the clean install the capture problems will be cleared-up as well.

Danny Fye
www.dannyfye.com
www.vidmus.com/scolvs

Am I missing something here?

If it's Windows XP, why can't you just do a system restore to a time just before the 7e install?

Because System Restore is not perfect. I always disable it after doing a clean install. Frees up drive space and a minimal amount of resources.

The problem is, Sys Restore isn't a complete duplicate of stuff, it's a partial duplicate. So you can revert back to an earlier time, but not everything reverts back. XP is the best version of Windows to date (including Vista), but it's not perfect.

Danny, you were prophetic about the card. I replaced it with a Dynex 3 Port IEEE1394 and tried it again -- it did the trick! It's also detecting the camera and capturing.

I'm still weary of going to 7.0e, but am ecstatic that I have a working system again.

-Dana Nathan Salsbury

I am glad that something works properly now and I am glad I was able to help!

As for Vegas 7e, well, I may spoken too quick.

The initial test I did was with an *.m2t file that was 48 minutes and it worked fine. In fact I just did another test with it to be sure and it worked fine again. I deleted the *.SFK file to make sure that the peaks were re-built.

I just did a church service with 2 cams and the files are 1 hour and 5 minutes for each file.

Now for the problem. If I load those files in Vegas 7e and build the peaks (be it the normal peaks or 8 bit) when it gets to 99% Vegas would stop. If I let it sit for 20 plus minutes then an error dialog about Vegas needing to shut down comes up.

I divided the files in approximately half and the peaks will build just fine.

So there seems to be a limit (at least on my system) as to how large/long an m2t file can be before the building of the peaks crap-out.

At least there is a work-around by cutting the files in half.

So it looks like we need Vegas 7F.

Danny Fye
www.dannyfye.com
www.vidmus.com/scolvs

I think there is a lot of truth to that. Building peaks seems to be the greatest problem that Vegas has. I forget, are you on 'd' or 'e'?

I am on 'e'. Even with the backups and all I didn't discover this one until way too late to go back. Even so, I have had various problems with peaks using earlier versions. So backups can be extremely helpful but nothing is guaranteed.

I think what Vegas needs is some better error trapping that will allow it to simply skip over problem areas of a file or when it gets to a max it would then just simply end the process instead of hanging up and crashing.

I'm sure there will be posts on the forums about Vegas not building peaks for parts of the file(s) and/or the end of the file(s) but then it should help somewhat with trouble shooting because then one can better determine if the problem is in the file or Vegas itself. Would also help in updates and fixes for Vegas.

As for now and at least on my system I will simply feed Vegas smaller bites of HDV so it won't choke on it. ;)

I am using Infiniticam to edit the cams so instead of one multi-cam-prep project I am using two of them. I can then copy the resultant events to the main project and finish it up there. I already did the first part this morning with the church service. After lunch I will copy the events to the main project and then finish it all up.

I never use the multicam project(s) for Infiniticam for the final project. I always copy the resultant events over to the main project so I don't have to deal with the clutter of the multicam project(s).

Danny Fye
www.dannyfye.com
www.vidmus.com/scolvs

My experiences....
 

I've been chasing an issue with Vegas 7 since the fall. I actually installed Vegas 7e in the hope that was the solution, but alas, it wasn't.

Over time, I've determined that the problem seems to be limited (at least on my system) to Vegas rendering to WMV/HD output. Could well be anything related to WMV, but I'm only using WMV for 1080i/1080p output right now.

The first problem I found was that I was getting really slow renders. This proved to be that, crazily enough, I was thrashing my main video drive (composed of three SATA drives in a RAID0 configuration). In other words, the drive simply couldn't keep up with the demands, despite the heavy CPU use in rendering. This was a combination of HDV, Cineform, and 6-8Mpixel JPEG files on input, with the aforementioned WMV/HD (1080i) output. Targeting any other disc for output solved this problem... which, at worst, could make a render take days longer than it ought to, and seemed to be unusually crashy.

With that solved, I still had occasional problems rendering to WMV/HD, usually resulting in crashes... the whole-system, blame it on a random device driver kind, which are really gnarly to debug. Again, only related to WMV rendering... I could (and did) output the whole project to CineForm files without any indicent... and those CineForm files rendered well to WMV/HD. I did, at one point, boost my swapspace, based on a theory that the WMV CODEC had some memory leak, which might be aggrevated when Vegas has all this extra memory needed for rendering large JPEGs to video, etc.

I have since had one crash, again on WMV/HD rendering, in the last month or so, but it's largely under control. I've recently updated a few of the system resources, just in case there were other related problems/aggrevations, but chasing these things down is often hit and miss.

Hopefully, if Vegas is actually doing things to contribute to this kind of instability, they'll find it and fix it... soon. I'm totally not used to Vegas being any kind of problem; I've been using Vegas since the Vegas Pro (audio only) days, and it's been one of the most reliable programs I've used, in any field.

One more thing...
 

I do know Vegas isn't terribly error resistant... and that's somewhat to be expected, you don't usually get speed and error-checking together. I had a non-HD project, actually rendering a WMV download as a DVD for a family member. The WMV had a number of small glitches in it... these show up red on the timeline, and more often than not, they crash when you try to render said video. The problem, of course, was actually finding these... sometimes only a few frames were disturbed, over several hours of video.

If you get glitches during HDV capture/transfer, it's very reasonable to expect the same kind of bad behavior. I have found Sony's built-in HDV capture less reliable on my system (nForce4 motherboard, AMD64x2 CPU) than HDVSplit in this regard.

For single-pass renders to MPEG (for that DVD), I was actually able to use the incomplete MPEG file to track down the nearly hidden glitch. If you're crashing during HDV renders, try looking for glitches in a similar way; maybe try rendering the whole timeline to something relatively fast like CineForm.

If you have a software RAID and with the heavy load on the processor then that would significantly reduce the effectiveness of the RAID it seems. My questions in another thread concerning RAID and subsequently my studies of it have helped me know that if one was to use RAID that it really needs to be a true hardware RAID with no software involved at all. A true RAID controller costs at least $300.00 from what I have found.


I always let Windows size the swap instead of fixing it. I used to use a fixed size but I would always run into problems having done so. Even if I were to use four times the amount of ram I have.


As for fixing the bugs in Vegas, they have to also track down the causes and duplicate them to be able to fix them. When I did troubleshooting while working on televisions and other electronics at times there would be one of those "dogs" as we called them that would take a lot of extra time to figure out. Especially the ones that were intermittent. So some of these problems will take somewhat longer to solve than others.

Danny Fye
www.dannyfye.com
www.vidmus.com/scolvs

You're of course talking about a "smart" RAID controller (eg, one with its own CPU that implements the disc spanning or, usually, more complex RAID protocols such as RAID 5's distributed model) rather than a "dumb" RAID controller or OS-managed stripeset (eg, no CPU of its own), since of course, there's really no such thing as a "hardware" RAID (they all use both hardware and software). In my case, my primary video RAID is running on a dedicated Silicon Image controller, which is of course managed by BIOS level software at boot time, and a Windows driver at runtime.

Thing is, a level 0 RAID is using a very trivial amount of code... no more CPU overhead than your normal filesystem (in fact, in a Windows stripeset, it IS your normal filesystem, just partitioned across multiple drives). Companies like Silicon Image sell smart controller chips, which add on-chip processors much the same way most SCSI controllers went "smart" back in the 1990s. These start at $5 for the chip itself... not a whole implementation, but also not something that need cost $300 in order to be real.

What's obvious about any RAID, when you think about it, and very nicely demonstrated by the slowdown I experienced, is that a RAID is going to be slower seeking than a single drive. Basically, on a single drive, your seek time will average out to the average seek time of the drive... sometimes slower, sometimes faster. With a RAID, however, your seeks per logical block is going to be the worst case seek of the N drives in your array that comprise that logical block. This may be somewhat offset by the fact your logical blocks are now N times larger.

But when I'm jumping around between 50GB CineForm files, dozens of 6 and 8Mpixel JPEGs, etc. that's lots of seeking. The reason the problem was obvious was simple: with all this stuff going on, reading the drive, compositing, rendering to WMV/HD, I was seeing dead cycles... sometimes the CPU use didn't rise above 70-80%. The only reason that could happen is some kind of I/O blocking.. the only reason for I/O blocking would be that somehow I became hard drive bound rather than CPU bound. While I certainly have a fast CPU (well, it's 2006-fast, an AMD64x2 4400), it's insane to believe the drives should be that slow.

And of course, they weren't, if the drive speed had not had such a high component of seek time. Pointing the output a different array (or single drive, it doesn't matter) was enough to eliminate any CPU dead space in there... and that extra day or so of rendering, even when it didn't crash.

Of course they do... this is what software developers spend much of their time doing (and hardware developers... I've done both professionally, but tend toward hardware). They don't fix bugs they don't know about; they do try to fix bugs they know about, and the best possible description of the bug is the key to reporting it... you want to give the developer the ability to reproduce it from your description.