musicvid, when I try that, the take name is the video file that it SHOULD be, but it's not actually displaying (and doesn't render) the information from that file. And I can no longer see both files in the project media; it's always the most recent I've tried to bring back in.

BTW, there is nothing wrong with the original files. They are what they should be. This issue just appeared out of the blue near the end of the production! :(

This is the second time in a week that something similar has been reported, all of a sudden the last report is no longer an isolated incident.

Yep, I had the same problem and solved it by deleting the offending file.

What version of Vegas are you using? Is this a reproducible 9.0 bug? Inquiring minds want to know.

[Proposed Alternate Explanation]

How do you know Vegas is at fault?

In database terms, what you see is a "label", which is a text field, not the file name. This label can be edited by the user.

Nobody in their right mind would design a DB schema that would take end-user data as an "index".

More likely, something got "jiggered" on the timeline accidentally and was unnoticed until later.

Vegas does give you enough rope to......

In "technical" terms, data fields are often referenced by "GUID's", or concatenations of fields with GUID's, and only part of the index is displayed to the user. Take the case of two "Dr. Smith's" in a contact DB.

====================================
Vegas is confusing a couple of my video files.

"Take the case of two "Dr. Smith's" in a contact DB. "

You cannot generate two GUIDs from two "Dr Smiths". you need another data item such as ZIP code or full address, birthday etc. If even with all that data you still cannot resolve two different GUIDs then you're stuck. Better to create or expose a unique key to the user e.g. Client Number.

I have a suspicion the problem here though could go back a long way in the history of Vegas. Long ago we had a problem with Vegas inserting a black frame and/or a frame from the wrong piece of video. As far as I recall it was always from video that was on the T/L or in the media pool. That indicates that the problem was not that the GUID referenced the wrong file, rather that Vegas believed the wrong file or frame belonged at that point on the T/L.
How I think this can happen is because Vegas does not use frames internally, it uses time and from the time value decides which frame (timecode) belongs where. If you doubt that assertion remember that Vegas will quite happily let you edit video without it being quantized to frames.

Bob.

Make it four... I'm pretty sure this is similar (if not the same) problem I reported back in September of last year here. I have completed that project and really not seen the problem again since, but I know it was there. Wish I had checked out the particulars some more. I was under the gun to finish the project so I dropped my investigation of it.

Ted

Bob, yeah that's what a lot of DB's do that cover a small domain, and maybe that's the problem, the Vegas GUID's aren't globally unique.

I wonder if deleting the original .sfk (for a clip), and then Vegas has to recreate it, but under a different circumstance and condition, and that's when the conflict is or "may" be introduced.

Because you mentioned before that an .sfk is a pointer and only contains references.

I'm sure Vegas has some way to know if an .sfk has been changed, maybe something like MD5 Hash, but if a user does a lot of media sharing between projects, "copies media with project", cuts and pastes a lot, etc. no doubt a conflict can arise.

"Versioning" or resolving record locks is practically a whole science in itself. It's like a constant "which came first, the chicken...". It's so complicated, that most DB's are not "live" and have to propagate changes via a synchronizer that goes through and checks for conflicts.

And what about unique scenarios where the same clip is opened in another Vegas instance?

I think its Vegass problem - a very old problem.
I posted on another forum (Cows) back in 2004. I was new to V4 then. It also happened in V5.
Here's the link to that thread
http://forums.creativecow.net/archivethread/24/651344#651538

As it has been said, 'delete' key is the only solution.

Vegas Pro 9.0c

I had tried deleting the sfk files corresponding to these video files, but that didn't work. My main goal to DVD is done. I'll just have to add new takes AGAIN when I render to blu ray and Zune formats. Sheesh.

I had the problem in Vegas 9.0c

Oh well, I've just been bitten by this as well and I mean bitten hard. Of course Murphy is also involved, this is one of the few times I'm trying to meet a deadline :(

Bob.

I found a moment to have a look see what was going on.

According to the T/L and what the previous version of the project should be on the track comprises, is Tape 644 Clip001.m2t. What is actually on the T/L is Tape 645 Clip001.m2t. I note that the Active Take label shows it as Tape 644 Clip 001.m2t.
Checking Project Media I find it has no reference to the correct media, instead it shows Tape 645 Clip001.m2t as being in the pool. So I think easily fixed and select Replace, select Tape 644 Clip 001.m2t and guess what, nothing changes, the project still shows the wrong thumbnails and it's feeding the wrong video out.

As much as I hate to say this, BudWzr might have been onto something, it looks like something got messed up in the project file involving a hashing table and there's no easy way to put this right, bummer.

Bob.

Based on your report, I think Vegas' database engine ignores the space in the name. That's why programmers NameThingsLikeThis.

I'm guessing that the active take label is concatenated with a GUID, or joined with other fields and THAT becomes the GUID, and that's where the space gets dropped, and the old reference is overwritten.

Nothing changes when you try to "replace", because in effect "Clip 001" and "Clip001" are the same to the database.

Labels are "text" fields, so they don't matter for display purposes, that explains why the label is correct.

The best workaround for this is to ALWAYS use the same naming convention.

I hope SCS can throw me some swag if I'm right, but not mention anything if I'm wrong. :)

Your theory is good as a theory but fails in practice as it's mixing up the "Tape 644" part with "Tape 645" plus as I said it's only getting it mixed up in one part of the processing.
Just for the record Veg files are packed binary using some obscure format, a search back a few years would find an SCS person giving the correct name of the system. It would be nice to have an option to back them up as text files. Over the years I've had several instances of project files becoming unreadable and no one, including SCS could fathom the problem.

Bob.

Do these clips have ANYTHING in common? Like being in more than one project or in THAT project then removed? Anything at all like that?

Is each "Tape 4XX....." in a separate project? Never together?

Any "Nested Veggies"?

(I'm working hard for that swagbag")

P.S. It doesn't matter what database engine they use, the rules are the same. It's a logic error or else the backup restore should solve the problem. Both files can't get corrupted coincidentally at the same time.

Do these clips have ANYTHING in common? Like being in more than one project or in THAT project then removed? Anything at all like that?
Yes, BUT the project media was flushed, project names incremented etc, etc many versions before this problem arose.

Is each "Tape 4XX....." in a separate project? Never together?
Yes.

Any "Nested Veggies"?
No.

Bob.

Can you think of any reason why the error is so close and correct in number sequence?

How would a Vegas project know that a "Tape XXX" other than the one on the TL existed?

Do you still think "flushing" a project and saving using number increments is safe? Is that your normal workflow, to "bubble" the project to final render?

So the output from project "Tape001" becomes the input to project "Tape002", that certainly SEEMS innocent enough and makes sense.

In database terms that's a lot like "recursive data". Where C is derived from A+B, and gets ridiculous real fast, but that's not exactly the same issue here.

Has anyone that had this problem been using the same workflow? Recycling the project file with a "save as"?

I'm thinking the data tables are not getting emptied because you're basically just renaming the file, or taking a "snapshot". Nothing there to tell Vegas to wipe the tables.

You're just leaving a copy behind. That means the media isn't "flushed" until AFTER the save as.

Granted, the "bug" only shows under special circumstances, like old data is present AND some other condition, like there's a space in the label? And when the data is passed to the tables it gets stripped out, and somehow the save doesn't complete?

What I'm thinking now is that somehow swapping in a new file with the same label doesn't register as an update, and that's VERY curious.

Does the new file have the same, or similar name as the old one?

There's a "Tape Name" field in subclip properties 2nd tab. Do you use this? Default is blank.