Replace Footage Bug strikes in V11 build 682

larry-peter wrote on 11/1/2012, 6:35 PM
I had to take a minute to calm down before posting this. After running smoothly on 594 since it was released, and on 682 for two months (haven't moved to the latest build yet and right now not quite sure which NLE direction I'm going in) the bug has hit in the end stages of a 2-hour-long documentary edit.

My editor had copied/pasted clips from multiple instances of Vegas on several occasions over the past few weeks and today on opening the project it was severely compromised to say the least. Thank god for Timeline Tools. I'm too flustered now to recall the author at the moment, but if Sony hasn't given you MONEY for it yet, something is very wrong.

I made detailed notes of every correction that I made, and will try to repro all the copy/pastes exactly so I can report to SCS every step that was made prior to the disaster. In each instance of a replaced clip, the active take name (in this case always numbers) was changed from the original take name - which had matched the file number of the camera clips in the project before corruption. After the bug hit, Edit Details showed that a new path had been assigned to each wrong clip which contained the correct file name/number, but pointed to a different directory path!

For example, if the original correct clip had a Take Name of 00050, and was located at Projects/Exteriors/00050.mts, the replaced clip would have a take name of 00049 and Edit Details would show its path as Projects/Interiors/00050.mts. And the new (wrong) paths went to multiple directories, not just the same one repeatedly. Hope I'm being clear - If I'm too frazzled to make sense now, my next post will after I regain some composure.

Timeline Tools found several other clips with mismatches between Take Name/Path that were probably ripe for replacement on next project load, so I corrected them as well. (To clarify, the clips on the timeline and their paths were correct, but the take names had been altered)

I recall release notes saying this had been solved in 510/511?? This is such B.S.! Perhaps its time to take my blinders off. Just because I LIKE Vegas, and have defended it for years, I'm not willing to sacrifice my career for it.

Comments

videoITguy wrote on 11/1/2012, 10:23 PM
Could be wrong, but don't think that I have ever seen announcement of problem solved. There was a moment when some reported that the bug was lessening in appearance, kind of like the cold virus being momentarily stuck in China - that won't last long with airline travel being what it is!!

Thank goodness for TimelineTools analytical ability to test this!!
NickHope wrote on 11/2/2012, 2:43 AM
The version 11 build 510/511 release notes stated "Fixed an issue that could cause events to use the wrong media in certain circumstances (seen when project is later loaded)." But a number of people have seen the replaced footage bug since then.

Perhaps that note was referring to something different. More likely it seems to me that it's not simply a case of an error in the code, but rather some underlying issue with the database or memory management that is somewhat outside the control of the developers. So they might well have improved the situation, for example by changing the value of a buffer or something, but they have not been able to eradicate it completely.

I would love it if someone wrote a script which runs in the background or whenever a project is opened, that runs just the "show misnamed takes & media" functionality of Timeline Tools, and actually flashes up a warning when it happens, rather than us having to dig into Timeline Tools to look for it. Knowing exactly when the problem starts would also be useful in diagnosing the bug.
ritsmer wrote on 11/2/2012, 4:00 AM
Had the same replaced footage issue and submitted a support ticket with info and documentation.
On september, 25 2012 I got a message that it was solved with the new build 700/701.
After installing Build 700 I have not seen the issue here - and have started to copy/paste from Vegas-to-Vegas again.

The great Timeline Tools is written by Gary James, MOA Software L.L.C. - and it really has saved me a lot of time by spotting replaced media.

You find it here: http://www.nfatoys.com/moasoftwarellc/Default.htm
larry-peter wrote on 11/2/2012, 8:19 AM
@ritsmer, did you actually get a communication from SCS that the bug was solved in 700/701? If so, I may give it a shot. I gradually waded back into copy/pasting after the 510/511 release notes stated it (or "something") had been fixed and began doing it fairly regularly. This is the first time the replace has occurred. It happened using instances of the 32bit version with VERY large timelines (some had four hours of AVCHD footage) so I wonder if each time the issue is marked "resolved" something has just been done to increase the threshold for the error to occur, i.e. memory usage, database size.
I'm generally such a positive person that I make others ill, and when I look at some of my past posts I would perhaps shout "fanboy" at myself. Right now I have the attitude: Fool me 23 times, shame on you. Fool me 24 times, shame on me. Occasional crashes I can handle. Re-edit my work behind my back, and we're enemies. My work and my reputation are what feeds my family.
farss wrote on 11/2/2012, 8:32 AM
Never have the relases notes said this bug was fixed, the word "may" was in there.

I don't see anything in the V11 700/701 release notes about this bug either.
Unless they were so ashamed of it that they decided not to mention it ever again and hide that they'd even fixed it we have to assume it is not fixed.

Bob.
larry-peter wrote on 11/2/2012, 8:51 AM
Bob, I just want to take this opportunity to thank you for all your contributions to the forum. While I remained an idealist, you have always been a realist. I appreciate you calling 'em as you see 'em all these years, as well as continuing to offer advice to all. I'm starting to open my eyes. Thanks.

Larry


ritsmer wrote on 11/2/2012, 10:53 AM
@atom12 - Support answered my ticket "Vegas changes media on the timeline" submitted with proper documentation etc., as follows: "An update of the application was released which resolves issues relating to this incident. You may download the update here. "

Thereafter I downloaded and installed the said update - and have not seen the issue since then.
I have not bothered to check the release notes - main thing for me is that this pesky issue was solved.
larry-peter wrote on 11/2/2012, 11:32 AM
@ritsmer. Thanks for clarifying. I'll give the new build a try.

"Whap!" "Thank you sir, may I have another?"
Gary James wrote on 11/2/2012, 11:51 AM
"I would love it if someone wrote a script which runs in the background or whenever a project is opened, that runs just the "show misnamed takes & media" functionality of Timeline Tools, and actually flashes up a warning when it happens, rather than us having to dig into Timeline Tools to look for it. Knowing exactly when the problem starts would also be useful in diagnosing the bug."

Nick, If you're running Timeline Tools and have the Show misnamed Takes & Media display filter selected, many of the normal Vegas editing tasks cause the main display grid to be automatically refreshed. If an error causes the problem to appear, it will immediately show up in the list of bad events. The problem is, Vegas doesn't inform extension programs like TLT of changes that occur for every editing activity. So even a special purpose extension program as you suggest would fair no better in detecting the problems.

There is a work around though if you are determined to track down the cause of the problem. After each editing operation, click the TLT Refresh Table button. This will immediately show you if a problem appeared in the last editing operation.
videoITguy wrote on 11/2/2012, 11:57 AM
This is good info about Timeline Tools and should be included as an addendum in the dcoumentation piece for this excellent invaluable tool.
Randy Brown wrote on 11/7/2012, 10:51 AM
The great Timeline Tools is written by Gary James, MOA Software L.L.C. - and it really has saved me a lot of time by spotting replaced media.

I'm still waiting on the final verdict if the bug is fixed before buying V12 and still on V10.
I've installed Timeline Tools, can someone please explain how it helps with the replaced media bug?
I have a clip in a project that was replaced and in Timeline Tools I've selected "show misnamed Takes & Media" but nothing shows up.
How does the software help with this ludicrous bug?
Thanks,
Randy
larry-peter wrote on 11/7/2012, 2:49 PM
@Randy,
In all of my cases where the bug has struck, one of two things happened: Either the take name and media file name (as shown in Edit Details) no longer matched OR the names still matched but the path to the media file had been changed to a different folder containing a clip with the same name. If the latter occurs, TLT may not catch it. In my case it did because in the instance the new path happened the original media file was 0002.mts and the new (replaced) file was 0002.m2t.

If you're a new user of TLT, perhaps you made a mistake I did at first - when checking for mismatched media (or anything else) it defaults to a single video or audio track that you may have to change in the pulldown box. There's also a pulldown option to monitor all tracks.

Also will warn that once a project (at least in build 682) experiences the bug it replicates in a way that feels like a computer virus infection. One project (3 were hit the same day) has had every clip fixed, then renamed as a new project 3 times. On opening, NEW clips would be replaced. I think I finally solved this by moving the project and media files to a new folder on a new drive. This really seems like a limit for database size is being hit and once exceeded, it's corrupt. Either that or it is some virus-like data replication gone wild within the program when some unknown action triggers it.

My feelings about the bug supposedly being fixed: If it was true, I would think SCS would be trumpeting this accomplishment. And also if it was true I think they would explain the process to us along with how to fix it when it occurs. I think they may have introduced a new, higher threshold for the bug's appearance. Whatever new threshold has been achieved, once it is exceeded I'll bet the bug has a chance of occurring again.
Larry
Randy Brown wrote on 11/7/2012, 3:01 PM
...OR the names still matched but the path to the media file had been changed to a different folder containing a clip with the same name. If the latter occurs, TLT may not catch it...
Yes that's the only way I've ever seen it.
If it hasn't been fixed I'll be forced to switch NLEs....a damn shame because I've loved Vegas since V2...it's just unbelievable that this bug could still exist after all these years!
Thanks for your time,
Randy
larry-peter wrote on 11/7/2012, 3:38 PM
You know, I have to wonder if when the database becomes corrupt (if that's what's happening) something similar to the "search for media in new location" that happens at project start is triggered. The new paths sometimes aren't connected to the current project or the project copied/pasted from. In the case I mentioned above, the .mts file was 1080 and the replaced file was 720. How is Vegas deriving the new path if the project doesn't know the path even exists?


Randy Brown wrote on 11/7/2012, 4:56 PM
That sounds logical but it seems I've read where people said it's happened to them without opening/closing so I dunno...I do know it's a PITA though!
Zeitgeist wrote on 11/7/2012, 5:22 PM
I've had my footage replaced only in the project media tab but not in the timeline in Vegas 12. All my footage suddenly became solids numerically named in the hundreds & the clips with their proper names disappeared. I think the bug has something to do with copy/paste & using too many or certain plugs. The timeline became very sluggish. It rendered out fine, but the project media tab had a glaring inconsistency.
Randy Brown wrote on 11/7/2012, 5:35 PM
I think the bug has something to do with copy/paste & using too many or certain plugs.
Others have mentioned your copy/paste theory and some have even suggested just not copy/pasting....my thoughts were ...huh?
That said, it seems the only time I have the issue is when it's a project that I copy/paste from another....I'd just like to hear from SCS stating they acknowledge the problem and it is on their priority list to fix.
Zeitgeist wrote on 11/7/2012, 7:04 PM
I was copying & pasting from the same timeline. The clips had a lot of plugs. I've noticed Vegas is less stable the more plugs used. In the past, when I opened a project plugs would duplicate themselves on the same clip.

Stacking plugs makes Vegas less stable. The color match plug stacked with other plugs & copy/paste caused me problems. I had to remove color match all together from the project to get it to render completely with gpu off. Otherwise the render stuck midway. Going back to a sequentially saved project before the copy/paste & then removing the color match plug with gpu off saved the day & got me through the edit.

Copy/paste without the plugs never caused a problem.

NickHope wrote on 11/7/2012, 11:42 PM
When I was getting the bug it was always after copying and pasting between large projects in 10.0e. I simply don't copy and paste any more (still using 10.0e) and haven't had the bug for a good while.
Former user wrote on 11/8/2012, 7:34 AM
When this problem came to the forefront before, we could never find a concensus on the cause.

Dave T2
jimsch wrote on 11/8/2012, 7:54 AM
I am testing a theory - was Windows Indexing enabled on the drive that the files were stored on?

To Check go to My Computer, RC the drive, Properties, Is Indexing turned on?
Randy Brown wrote on 11/8/2012, 7:55 AM
I can say it has nothing to do with plugs (for me)....these are rough edits for me...just chopping up longer raw clips and moving them to another project.
I suppose it's encouraging to hear people say it doesn't happen as long as you don't copy/paste but I just don't see that as being an option.
larry-peter wrote on 11/8/2012, 8:42 AM
@jimsch. I understand where you theory is going, but indexing is off on my system. Also no plug ins at all were used on these timelines. As stated in the original post, these were big timelines - over 6 hours of AVCHD on a system with 16 G RAM - and I haven't seen this bug since 8.0 was new.

Logically it seems that there is some limit to what can be buffered in RAM during a copy/paste when you add that to the RAM resources already consumed by the project and media. Probably is different on every system and having plugins using additional resources might lower the threshold. And for those who didn't copy/paste prior to seeing it, perhaps the complexity of the project and amount of footage/plugins was consuming enough RAM in ratio to available RAM that the error strikes when saving. It MUST have something to do with moving info from a buffer during a write to HD. Wouldn't you think?

It's all mental you-know-what until we hear something from SCS.

One new thing I've discovered when I went back to examine the projects (incrementally saved by Timeline Tools) that were experiencing clip replacement on startup - Timeline Tools showed some clips (that were still correct on the timeline, and matched media name to clip) had their size properties reduced to 0 X 0 pixels. These were some of the clips that would be replaced on the next startup. Some sort of project-wide database corruption is happening.
jimsch wrote on 11/8/2012, 9:04 AM
Thanks atom12.

I was struck by this in V11-682. It was a 2-3 hour project file, 200+/- clips, 20-30 tracks of video/audio, and I was cutting & pasting between the timeline itself as well as another open instance of V11. Upon investigation I did notice on mine that it seemed to happen to clips that had been reversed and therefore became a sub-clip. I could never pin it down any further than that.

I raised the Indexing issue because of the fact that I was having constant crashes on that project while just trying to playback the timeline. If I moved a clip and then hit L to play, Veg would crash. Sometimes I didn't have to move anything.

I saw this post today, http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=837405&Replies=2, and it triggered a thought regarding DRP. Since turning off indexing on my drives that contains the media files, I can set DRP to 2048 and playback is rock solid, no crashes yet. Fingers crossed.