Vegas is wasting my money......

Comments

CorTed wrote on 12/17/2008, 2:06 PM
Bob, you just got ahead of me on this:

John Cline wrote "Personally, I only see Vegas rebuilding peaks on unmodified existing files twice a year; when we change to/from Daylight Savings Time."

I do not get that at all. How does the time change on a computer make Vegas decide to build peak files??
That can't be right

Ted
John_Cline wrote on 12/17/2008, 2:34 PM
"From what you're saying then Vegas modifies the file everytime it opens it and hence changes that time stamp."

No, Windows updates the "accessed" time stamp every time a file is opened, but unless the file is actually changed in some way, it does not update the modified timestamp. Vegas doesn't appear to modify the file just by opening it, it does seem to store the media file's modified time stamp in the peak file and checks this time whenever it opens a Vegas project.

There is a setting in the registry to disable Windows from updating the "NTFS Last Accesed" stamp and a few Windows "Tweaker" applications may make this registry modification because it speeds disc access quite a bit, but I know of no way to change Windows behavior when it comes to disabling the "Modified" time stamp. In fact, that could be quite dangerous. I still think there is some background application that it "touching" Bruceo's media files and causing Vegas to rebuild peaks. It's extremely unlikely that Vegas is causing this.

You can right-click on a file and go to "Properties" to see the created, modified and accessed timestamps. That might provide a clue to see if the file's have actually been modified since they were created. Once a file has been written to disc and it hasn't been moved or changed, the created and modified time stamps should be the same value.
johnmeyer wrote on 12/17/2008, 2:35 PM
I finally installed and have been using 8.0c (see my earlier thread on AVCHD). So, I tried to make the peaks rebuild.

1. I set the clock ahead a few hours, re-opened Vegas and re-opened a saved project. No re-building.

2. I move the files (including the SFKs) to a network drive. I dragged the copied files onto the Vegas timeline. No peak re-building.

3. I looked at the hidden internal preferences to see if there is something that could be set and that would get you into trouble. There are actually a few settings, but I didn't want to play with them at this point.

The MM idea is the most intriguing. I don't use it, and I cannot get the peaks to re-build. The other idea that this might relate to having a really large number of files -- or really long total length -- is also intriguing. There could be some sort of memory breakdown or leak. How much RAM memory does he have, and which O/S (XP, Vista, 32 or 64 bit) is being used?

Certainly, if I were him, I would try turning off media manager, if it is enabled. I would also consider resetting all preferences (press and hold Shift while starting Vegas -- or is it Ctrl?). That is a bit of a pain because you have to re-do the toolbar and everything else, but it would at least undo any setting that may be causing this problem.

[edit] I just read:

I still think there is some background application that it "touching" Bruceo's media files and causing Vegas to rebuild peaks. It's extremely unlikely that Vegas is causing this.

Perhaps he could write down the "modified date/time" for a few of the SFK files and see if these get changed between when he saves the VEG file and when that VEG is next re-opened?
blink3times wrote on 12/17/2008, 3:01 PM
"The MM idea is the most intriguing."
It can't be MM.
I use MM with no issues.
I don't know how RAID works with actual files but could a RAID system possibly mess with the files somehow?

"The other idea that this might relate to having a really large number of files"
I just don't see how this could be. Either the sfk file is there, vegas sees it, and uses it..... or it doesn't see it, or feels it invalid and it doesn't get used. I don't see how 'x' number of files would play a role in recognizing/not recognizing the sfk files.
farss wrote on 12/17/2008, 3:01 PM
As you've probably read John despite my best efforts I cannot repo this problem myself. I've had it happen to me only extremely rarely, maybe once or twice in thousands of projects.

What this needs is the people who have this problem to get involved, that's the only way we'll find the differential. It is kind of frustrating, I've spent around 2 hours of my time trying to repo the problem and there's barely any response from those who say they're having this problem. Heck, if they're loosing an hour per day waiting for peaks to rebuild they should have the time to check in here.

Bob.
bsuratt wrote on 12/17/2008, 3:17 PM
<<I don't know how RAID works with actual files but could a RAID system possibly mess with the files somehow?>>

All of my video files are on RAID5 with no rebuilding problem.
bruceo wrote on 12/17/2008, 5:34 PM
"But that rebuild time is not down time for me. I keep right on editing. As a matter of fact, the first time I used Vegas, I did not notice it building the peaks. By the time I noticed it, I had already completed half my editing work."

Absolutely no way you are doing this on HDV Even on the fastest machines, unless you are on a properly configured raid or equivalent your drives will bog down. Its hard enough for vegas to maintain 29.9 unloaded much less adding a processor/drive intensive beak building session. If you wanted to deal with reduced framerate sure you can edit, but do one thing that gets queued and then you cannot complete it until the peaks are done sometimes 2-5 hours later on a quad machine with 4GB ram..... Try an undo or a save...... You must be doing 1 minute projects with 2 cuts......
bruceo wrote on 12/17/2008, 5:44 PM
"The other thing I'd like to know is if bruceo is using MM. I seem to recall he does and copies a common MM database between all his edit system regularly to keep them up to date. I'm wondering if this could be what causes Vegas to decide the peak files are dirty and hence need rebuilding. It's certainly a factor worth investigating, not too many use MM and not everyone is seeing this problem."

No MM is disabled and has been ever since it reared it's ugly head in V7.No shuffling of files. They always reside on an external USB project drive. Many different branded drives and many different computers. The one consistent thing is there was not a relatively consistent rebuild problem for 4 years with HDV until V8. Not always rebuilds, just much more often than ever.

tWe usually use Windows explorer and rarely but sometimes Vegas explorer. One of the amazing things that drew me to Vegas back in the day is how you could take any media from Windows explorer and just drop it into multiple Vegas time lines where with Avid & Premiere you had a painful import and conforming process. I still am amazed with what SoFo did with Vegas' powerful format agnostic capability almost a decade before any other NLE. Note: At the time Vegas was accomplishing this feat Apple was in shambles and just hired Jobs to come in and reinvent the company and FCP was not even conceptualized until 1-2 years later.
bruceo wrote on 12/17/2008, 6:03 PM
"I still think there is some background application that it "touching" Bruceo's media files and causing Vegas to rebuild peaks. It's extremely unlikely that Vegas is causing this."

I would consider this a possibility if it werent for the fact that my Vegas machine is a totally clean Vista install with no OEM junk or background processes and this behavior is exhibited on at least 4 different editors that I personally know across at least 6-8 systems. SCS has largely fixed the HDV reader/render issues, but the audio issues still need major attention.
bruceo wrote on 12/17/2008, 6:04 PM
"As you've probably read John despite my best efforts I cannot repo this problem myself. I've had it happen to me only extremely rarely, maybe once or twice in thousands of projects."

Bob, Where do your source files reside?
farss wrote on 12/17/2008, 6:58 PM
"Bob, Where do your source files reside? "

Local SATA hard disk. For my extreme test it is a SATA 1TB drive.

Bob.
farss wrote on 12/17/2008, 7:05 PM
"The one consistent thing is there was not a relatively consistent rebuild problem for 4 years with HDV until V8. Not always rebuilds, just much more often than ever."

Well there's a clue. Which version of V8.0?

I'm still running 8.0b because the thought of waiting for it to build 2 sets of audio track for HDV is too much to bear.

What troubles me is you say it's taking 4-5hours. Worst case with 18 hours of video I can get is 62 minutes and that's from an almost full 1TB drive.

It could have something to do with you using USB drives.
I have a fellow Vegas user who had nothing but wierd problems rendering from a USB drive. He'd get what looked like tape dropouts at random points througout the rendered video. Switching to firewire drives cured the problem.
Can't say for certain your problem is the same but heck, if it's costing you that much time a couple of firewire drive would be a good investment just to see if that cures the problem. I'd also consider switching to eSATA.

Bob.
johnmeyer wrote on 12/17/2008, 7:46 PM
I have definitely experienced several bad things with USB drives, such as playback stopping for five seconds and then re-starting, something which never happens with internal drives. However, I've always thought that was because of the age of my computer and the fact that USB 2.0 was still fairly new "way back then." It would be certainly worth a try to see if the problem can be reproduced with all the files on an internal drive.
kairosmatt wrote on 12/17/2008, 7:51 PM
Just a thought: I've been having problems with HDV and building peaks, but only if I don't capture the media through Vegas.

Do you use Vegas to capture, or an outside app?

blink3times wrote on 12/17/2008, 8:30 PM
"They always reside on an external USB project drive."

Correct me if I'm wrong but i thought you said you're using this usb drive on different machines? If this is the case then have you assigned the SAME drive letter to the usb drive for each machine... or is it F drive on one machine.... G drive on another?

Is the usb drive optimized for quick removal or for performance involving cache-ing. How are you disconnecting the drive.... through safe hardware removal or are you just pulling the plug?

Are ALL your files located in the same folder on the drive or are they in different folders/directories/partitions?

I just finished playing with some files on a usb drive and I DID manage to get one rebuild so it clearly has something to do with external hard drives. I would suggest going with SATA connected directly to SATA connect..... none of this usb stuff. Make sure each machine sees that SATA as the SAME in terms of drive letters as well.
kairosmatt wrote on 12/17/2008, 8:50 PM
I have been using a USB drive to edit projects off the desktop on my laptop. I have noticed that whenever I come to the laptop many files (but not all-more than one though) have to have the peaks rebuilt.

Once I exit Vegas and go to safely remove the hard drive, I get the message that says it can't be removed. Even waiting a long while afterwards, still can't safely eject.

I once got tired and frustrated after 15 minutes of waiting, and just pulled the USB out. The error message (that pops up in the lower right corner of the taskbar next to the external hard ward icon) said something along the lines of couldn't finishing saving a .sfk file.

Don't know why those in particular would cause problems with externals, but maybe thats the case...

For the record the external hard drive is Western Digital 2TB MyBook.

kairosmatt
farss wrote on 12/17/2008, 9:25 PM
Windows cannot eject a drive while it is open. That includes it even being highlighted in Explorer. If you get the Cannot message no point waiting, you need to close anything that might still be referencing the drive.
Then Windows will eject it.
Took me a while to figure that out and like you I had a frustrating time of it until I did.

Bob.
farss wrote on 12/17/2008, 9:29 PM
I think your first theory is more likely. If the external drive is mapped to a different drive letter that could cause a rebuild. That can happen if the connection is eSATA, USB or firewire.

I got myself into quite a muddle recently with so many internal and external drives that I had two mapped to the same drive letter. That really had me baffled for a while.

The other possibility is using file or path names with non English characters in them. There's been a couple of bugs in recent releases related to this.

Bob.
fldave wrote on 12/17/2008, 10:00 PM
I haven't read all of the posts, just the first 15 or so. so sorry if I repeat something.

Yeah, it is a pain it the butt. I have a V7 project I have been working on for 8 months. I have V8 installed, but started the project in V7, so most of it will die in V7. Consider that I am actually working on 16 separate current .veg files. Double clicking always launches V8, not V7.

Every once in a while I double click a veg file instead of right clicking it and opening it up with V7. Double clicking automatically launches V8, which starts rebuilding my V7 peak files. I cancel that, but the damage is done. When I restart the project in V7, it has to rebuild one or more peak files.

Also, consider that I have six (6) 2.4 GB 96/24 wave files that are being rebuilt, so it messes up my progress quite frequently.


I chalk it up to V7-V8 clashing. So check to make sure all of your desktops accessing your media files are all running the EXACT version of Vegas.

kairosmatt wrote on 12/17/2008, 10:06 PM
Hi Bob,
When I have been going to eject the disc, everything is closed.Usually it just ejects no problem.

But if I have been recently editing a vegas project that uses lots of media from that drive, and then I close Vegas, this is when I find I have to wait, and wait and wait.... I checked task manager to see if there was something going but didn't see anything obvious , and there is no AV scanner or defragger or anything like that running on it.
To be fair, it doesn't always happen, but about 50% of the time.

kairosmatt

Grazie wrote on 12/18/2008, 12:40 AM
Is it possible that a USB stick/drive can skew the mapping?

Grazie
farss wrote on 12/18/2008, 1:35 AM
"Is it possible that a USB stick/drive can skew the mapping?"

No differently to any other drive that I can see.
There are some strange and transparent differences between thumb drives that messed me up no end but that was a Linux boot loader.

I've been working in DVDA, amazing how simply it can decide that a sound file belongs with a mpeg file or one can simply tell DVDA which file to use. If you do get it wrong and didn't realise, the outcome would be far worse than a muddled up peak file.

Bob.
Grazie wrote on 12/18/2008, 2:41 AM
No differently to any other drive that I can see.Sure, my point is that I use these USB thingies on the fly, and maybe the comings and goings even of this drive could skew what was an already VEgas-set set of external drives. It is more to do with the flexibility of an already acquired external drive array - and then long I come with a USB stick! That's my point. Are you saying then, no-more and less-than any other internal/external drive?

Grazie
farss wrote on 12/18/2008, 3:04 AM
"no-more and less-than any other internal/external drive?"

Yes.
I've gotten drives in a knot but I can't see how that'd modify timestamps. Just stopped me accessing one of the drives.

Bob.