I figured it out Vegas kills Volume index

DJPadre wrote on 7/9/2005, 9:34 AM
Vegas killing external drive system volume info on external drives through firewire...
Dont believe me, well ive got 2 drives nuked to prove it..

i left my machine sitting idly with vegas running while i took a break for a couple of hours..

now, i have 3 external cases, and its NOT those and ive never had this problem UNLESS i leave the app sitting idly, with media on an external drive

Now i dont know what causes this, but i have now lost 2 projects because of this and have had to rebuild 2 hard drives from scratch.
Not to mention the stupid hours it takes to recover these files, if recovery is possible at all...

I know its not the drives as ive used them in different ways as well as for media storage of projects. I know its not the firewire connection, as it has hapened from a PCI 1394 card, as well as the mainboard's inbuilt 1394 connection.
I know its not the drives, as i have used these for about 6 months each without a problem.

With each failure, its the same behaviour, being that the "volume index is corrupt and unreadable"
I dont know if Vegas has an issue with XP, or if XP is having issues with Vegas constant checking of the files during autosave or what have you.. and to be honest i really am over it..
Ive NEVER had this problem with any other app which uses external devices.. only Vegas when it sits idly and unused.

so what do we do as users to make sure that vegas doesnt corrupt this volume info?? I really dont think that its XP as i have 4 media drives here as well as a system drive (a mix of seagate and WD) and havent had a problem with those..

Im not impressed either way..

Comments

kkolbo wrote on 7/9/2005, 9:52 AM
I have to admit that I am surprized to hear this. I leave Vegas alone with projects open on external firewire and USB2 drives all of the time. The enclosures very in quality from cheap throw aways to nice Oxford controllers. My system will sit in that condition, either rendering or just idle for sometimes days. I have been doing that since version 3. hmmm.

This may be a shot in the dark but, what firewire card are you using in you machine. Is it a Dell by chance?
johnmeyer wrote on 7/9/2005, 10:44 AM
Anything is possible, but this does seem unlikely. Which version of Vegas are you running? If Vegas 6, are you running Media Manager?

I certainly don't want to make the insulting mistake of saying that, because it hasn't happened to me, it must be your fault. However, I sure haven't heard anyone else talk about this so, as you look for a way to stop this from happening, I would certainly recommend looking for other culprits in addition to Vegas.

I would suggest reading this Microsoft Knowledgebase article that describes your problem (no mention of Vegas):

Cannot Delete or Repair Corrupted File on NTFS Volume

You may also find useful information here:

C:\$Mft can not be written data will be lost...

and here:

'C:\$MFT is corrupt and unreadable

You can get lots more results using this Google search:

Google Search
DJPadre wrote on 7/9/2005, 12:26 PM
interesting...

usually i wouldnt put a post up like this unless i was sure it was the culprit and what ive experienced so far, its just that.. Vegas

im using an NTFS file system, win XP SP1 with Vegas 5. The HDD enclosures are Lacie, BlueEye, and another brand which i cant remember right now (its on the other side of the room)

im using a Pyro firewire card on an ABit IT7 Max2 series 2 mobo.

In th epast i do recall leaving vegas on its own for hours on end with the Lacie and everything was ok, but for some reason its now coorrupting things.. now i have inadvertantly renamed files as describe in the MS fault post. ie ive got file names such as "CLip 17 PREParation" and i think THAT may be something, but its not saying i cant delete these files.. however it (this MFT problem) doesnt happen in my IDE drives, only the ones using firewire..

Now as this is the second time in 4 days that this has occured I assumed this was a boot sector virus, however after runngin tests and diagnostics, its not that. I also ran other diagnostic utils for each respective drive, as well as search on ways to either retrieve or rebuild this file system.

All to no avail. The only salvagable parts were from using a program called getdataback, and that too didnt give me all my results. It would jstu save me hours of headache and work if i knew what the hell was going on..




ReneH wrote on 7/9/2005, 1:14 PM
i have an external firewire drive, Buslink, for several years, through version 3-5. No problem here. I live the litle bastard runnning for days with vegas running, again no probelms. maybe bad brand of drives.
Liam_Vegas wrote on 7/9/2005, 1:23 PM
Most of my work is done across multiple external drives (usually USB). Never had such a problem. I defintely would get drive write problems if using these drives in firewire mode... mostly if I had an attached firewire camera/deck in the mix (hence why I mostly use the drives in USB mode).
johnmeyer wrote on 7/9/2005, 1:26 PM
It wouldn't hurt to apply the Firewire XP patch, if you haven't already done so. It seems to fix quite a number of things, beyond just the one thing it supposedly fixed. The downside is that the data transfer, after the patch, is about 10% slower.

Firewire 1394 SP1 Solutions

If you have SP2, you need a different patch. I don't have the link for that.
Spot|DSE wrote on 7/9/2005, 4:22 PM
DJPadre,
I'd also have to dispute that Vegas is the problem. Most of our machines have external Firewire, including 3 Firewire RAIDS that are left on 24/7. Nothing being eaten on our end. While they're never all on, we've got over 60 FW enclosures, and roughly 30% of those are turned on at any given time. In fact, I'm transferring data from one over VPN as I type now.
Try the patch john mentions. Does your FW system or card require that you load any specific drivers? You SURE your card is OHCI certified, and not just OHCI emulative?
farss wrote on 7/9/2005, 4:50 PM
One issue I've had in the early days of using firewire drives was somehow related to the Enable LBA flag. The drive would look just fine until it was getting full and then we'd start to get Delayed Write Failure Errors and all hell would break loose, basically the drive became useless.
Thing is I'm not 100% certain what we did to stop this happening but the problem did take quite a while to rear its head, oftenly a capture session would seem to have been OK but when we went to shut the system down or add the files to the Vegas TL was the first sign of problems.
Bob.
GlennChan wrote on 7/9/2005, 5:17 PM
I have a Prolific chipset firewire enclosure. It would get delayed write failure messages and eventually the MFT (master file table or something) would totally crap itself and the drive would be corrupted. Your data would still be there.
Flashing the drive fixed it.

However, Lacie FW drives don't use that chipset. So that's probably not your problem.
Some of the Lacie drives with 2 hard drives inside may have a really high failure rate, but again that's probably not your problem.
Spot|DSE wrote on 7/9/2005, 6:15 PM
My experience has been that anything without the Oxford 922 chipset is potentially problematic. Some of the Wiebetec(sp?) are not Oxford, and after purchasing two of them, had nothing but failures.
DJPadre wrote on 7/9/2005, 7:38 PM
wow, im not the only one feeling this then..
funny though that it happens NOW and only after i let vegas sit idly...

ill do a restore then run that patch, and hope for teh best, until then, i have to now go back and recapture some footage.. lucky vegas and vidcap are one of the better suites out there which allow you to do this..
jlafferty wrote on 7/9/2005, 9:57 PM
Could a bad cable be the culprit?

I've had four external enclosures, and have had two of them fail over time. Acutally, three of six failed if you count the original I RMA'd along with its failed replacement.

Initially I had all of them daisy-chained and connected to my machine via a SB Audigy card, but after the most recent enclosure failure I tried to be pre-emptive about killing potentially bad variables -- I've now got a dedicated SIIG (TI based) firewire card, and two of my three drives in a Wiebetech case (the third in the only working Pyro case I have). All drives are attached to separate FW ports, not daisy-chained.

No problems so far. I've had this setup for perhaps 6 months.

I'm running SP1a and it's not patched. I've grown to distrust daisy-chaining FW devices after I started having hangups in Vegas and dropped frames once my number of devices exceeded 3. In addition to the two external enclosures, I've got a FW compact flash reader and my DV deck attached to the SIIG.

- jim
DJPadre wrote on 7/10/2005, 2:12 AM
ive never daisychained my firewire devices as i have enough cables here and ports available to be able to get a straight line into the systema as opposed to risking having one unit fail on me and bring down the other devices. Ive seen that happen before..

funny thing though, is that prior to this initial failure, it was running fine, no issues whatsoever.. i sorted that initial problem and thought i got over it (the actual enclosure is now dead (Lacie)
Anyways... i saved what i couldthen the OTHER salvaging drive failed (different cable, enclosure, hdd make, and port) (this one is directly connected to the mainboard, not the PCI Pyro 1394 card...

After all this, i still feel that Vegas is one of teh most stable NLEs on the market and considering how easy it was for me to realloate the newly recaptured files, batch capture those files, and how fast and efficiently vegas managed those recaptured files within the existing edit, (i never put veg files and vidcap files on the actual media drives) i still love the app..

ive run this patch and havent noticed any decrease in performance, maybe jsut actual initialisation, but thats livable.. id rather have a stable working system...