User defined breakpoint?

farss wrote on 2/1/2008, 2:13 AM
Well having V8 throw one of them at me was a new experience.
The nice message about how V8 would continue to run but mightn't be too reliable was an understatement. It continued to run, refused to do anything and refused to die until a hardware reset set it on it's way.

Further grief followed with more uninviting error messages from both V7 and V8. I might have found something worthy of further investigation.

The problems started when I tried to capture HDV from a HDV tape via my M15. Well it wouldn't work for the rather obvious reason that the deck was in DV mode. No problemo though I, switch it into HDV mode and all would be well, That was when things went rapidly downhill with V8 going nuts. So I rebooted via a hard reset, gave up on V8 and went to V7.

Still things were a mess. Removed unpowered firewire HDD from the firewire bus then things got back to normal. So I'm sweet but it seems to me that Vegas can be all too easily spun out completely by an errant firewire port. Many of the newer HDV devices will autoswitch between DV and HDV, Vegas needs to cope with this without going nuts. It's quite possible to create a tape with mixed DV and HDV on it. Vegas shouldn't loose the plot when the VCR switches modes. I'd hazard a guess even a glitch on a tape could cause the VCR to switch modes. That'd explain some of the current grief users are having.

In other words, Vegas needs to be better tested. Not just to ensure that it does what it needs to under ideal conditions but that it doesn't do anything that it shouldn't when things go wrong. Glitches on external devices are common, where tape is involved even moreso. It's not at all difficult to build a test case for these events.

Bob.

Comments

DJPadre wrote on 2/1/2008, 4:31 AM
this happened to us just the other week.
On my laptop with fingerprint reader, vegas totally nuked every USB and fireire device almsot frying my A1 along with it.

Vegas has always had issues with firewire, but not to this extent. In any case, i was lucky enough to recover everything by the system was still nuked within the registry. A restore fixed this but the fact remains that it was Vegas that caused teh problem..

I remember years back, we used to pitch vegas as being THE rock solid NLE to work with...

I cant say that anymore..
johnmeyer wrote on 2/1/2008, 7:50 AM
The hardest crash (direct to BIOS) I have experienced in over five years using this computer was when Vegas was capturing an HDV tape that also contained DV. When the tape switched, the computer went down hard.

However, I am not sure that it is all Vegas' fault. I too have had problems with Firewire drives misbehaving when a camcorder is turned on and plugged in (and also when a Firewire drive was added after the camcorder was already successfully connected). Mine is an older computer, so perhaps newer architectures are more solid, but my point is that I am not sure this is entirely a Vegas problem.
DJPadre wrote on 2/1/2008, 8:09 AM
john to be honest i really do believe its a vegas MBR issue...

as the encoders are active, and MBR is constantly writing while the capture takes place.. then BOOM...

Other times, when vegas "goes offline" when u jump apps, the MBR is again refreshed... in turn, i really do believe that this constant MBR access or access to the encoder//decoder for any given codec is the issue...

Ive had vegas kill too many HDD's for it to be a coinsidence
JHendrix wrote on 11/16/2008, 7:39 PM
VV8

User defined breakpoint notice upon crash


what does it mean?
TheHappyFriar wrote on 11/16/2008, 8:03 PM
strange, I had a tape with DV & HDV on it (accident) but when I would capture in VidCap it would work fine & when the HDV part came up nothing happened, it was a blank tape after that for all it cares.

Same when I captured HDV via Vegas 8 & hit a DV spot. I've only done this two times (one for each) but perhaps there's something else about it to, IE where it's writing to the drive, etc.