How is Vegas 7.0e working for you?

[Danny Fye]

Originally Posted by Dana Salsbury

>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

[Dana Salsbury]

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!

[Eric Shepherd]

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

[Danny Fye]

Originally Posted by Eric Shepherd

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).

------------------

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

[Bill Watson]

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?

[Eric Shepherd]

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.

[Dana Salsbury]

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

[Danny Fye]

Originally Posted by Dana Salsbury

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

[Dana Salsbury]

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'?

[Danny Fye]

Originally Posted by Dana Salsbury

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

[Dave Haynie]

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.

[Dave Haynie]

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.

[Danny Fye]

Originally Posted by Dave Haynie

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.

----------------------------------------------

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.

--------------------------------

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.

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

[Dave Haynie]

Originally Posted by Danny Fye

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.

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.

Originally Posted by Danny Fye

As for fixing the bugs in Vegas, they have to also track down the causes and duplicate them to be able to fix them.

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.