When did you receive confirmation from support they reproduced the problem?

This build has likely been locked down for a month. Also, once a problem is confirmed, that does not mean a fix has been identified.

A few observations.
1. Smart-render for Cineform files still broken. However, using the v10 avi dll still works.

2. Going back and forth between V12 and Sound Forge now seems to work OK, the main reason I went back to 394 from 486..

3. Folders you place in Favorites do not refresh. If you add/delete files, the changes will not show up--even after hitting the refresh icon. If you scroll down to the same folder within Explorer, you can see the changes. It seems that Favorites refreshes only if you close and re-start Vegas. Really a nice feature once it works properly. Perhaps someone else could confirm this.

4. It does seem to be quicker as others have mentioned.

wwaag

Nothing but crashes here.. I've never felt the need to go back to a previous build before, but 563 is totally unusable.

With a new project of just some AVC HD files from my Sony NEX5N and a wav file on the timeline, it crashes whilst playing every time. No effects or any of the usual culprits. Crashes with other projects too.

Unfortunately, the timecode issue with QuickTime files appears to be only partially fixed. To be fair, it isn't clear if this is due to the camera or to VP12 or to QuickTime.

The timecode seems to be read fine for .mov files created by Resolve and my Blackmagic Cinema Camera. However, .mov files created by my Canon 5D Mark III are still not read correctly. The timecode in 5D Mark III files seems to be read fine by MediaInfo and by Premiere Pro. Having said that, the timecode appears to not be embedded in exactly the same way as in the files created by Resolve.

Glenn, have you tried setting Preview RAM to zero?

JasonATL,

I didn't do much more than check to see if TC existed in my .mov files which were created by FCP when capturing from a DVCProHD tape source.

I've certainly seen problems with other media in the past where the method of recording TC in the file made a difference. For example, Vegas couldn't see the TC in a DV AVI file if Premiere had created it, and Premiere couldn't see the timecode in files created by Vegas.

Since SCS seems interested in addressing timecode readability these days (probably to make project interchange work), I think you should definitely report this.

Rob

Preview ram shouldn't have to be set to 0 in order to have Vegas work.

This is a big BUG! That everyone has their head in the sand about & accepts.

V11 did not have this problem. It is inherent to V12.

If this is the case for the indefinite future, then please, put the ram setting to a more reasonable location, so it may be accessed easier.

How about putting the ram setting control where the add to hitfilm button is...

Lovelight said, "Preview ram shouldn't have to be set to 0 in order to have Vegas work.

This is a big BUG! That everyone has their head in the sand about & accepts."

If I use the latest Nvidia driver THEN and ONLY THEN will I need to set the preview ram to zero! With driver 296.10 I can set the preview ram to the default 200 or even higher.

Nvidia has chosen to make their latest drivers such that they cause this. At least on my system it does.

So maybe you should find an Nvidia forum and complain there?

There ARE certain things that are truly beyond SCS's control. They can tell Nvidia that their drivers are causing problems and then it is up to Nvidia if they think Vegas or any NLE is more important than the games in which they seem to focus on when it comes to the lower priced cards. Do you think Nvidia will consider NLE's over the much more profitable games?

And NO!!! My head is not in the sand!!! So please do not make such assumptions!

IF "RAM Preview" does become a "Feature Point" of contention for users, then the whole subject needs a page and a half of explanation in the help file. The impacts of the feature, where it is suitable, where it is not, relationship to systems installs, - the subject needs complete clarity from SCS as to what their intentions are.

"Nvidia has chosen to make their latest drivers such that they cause this. At least on my system it does."

That's a bold statement.

See ya...

So far, so good here, too. I just loaded about 36gb of mxf files & thumbnails work fine. No crashes & it seems to load considerably faster. From the looks of some other comments on this forum I am glad I use an AMD video card & not a Nvidea. I am starting a project Monday morning. I will let everyone here know how if worked out before the end of the week.

Ignore my previous post here.. It seems to be running smoothly now. But here's what I did to fix it -

Firstly, I checked my ram, as I'd been getting a few BSOD crashes as well. But nothing wrong there. I also found a program to check my video card's ram. Nothing wrong there either.

Then I downloaded a program called SSD Fresh to optimise my my SSD system drive. I found I had a number of issues I had there actually, including the prefetch. So I optimised everything, which also disabled system restore.

Also, I'd noticed that for some reason I'd forgotten to set my computer to be optimised for background services.

After making these changes, I tried 563 again, and it's no longer crashing as it did before.

It looks like whatever was causing the issue working with sound forge also solved the issue working with files in photoshop. I can now make changes and save the file in photoshop without having to shut down vegas.

The Sound Forge issue appears to be cleared up on my machine as well. Will try out on a project this week to see if any other issues pop up...

@NormanPCN -- "The MainConcept AVC OpenCL problems with the AMD 7950 card not being detected/used still exists. 3 weeks and no support response"

FWIW confirm problems with AMD/ATI 7870 as well. Test encoding 1080p to 1080p, Sony AVC encoder shows between 30-40% CPU, 30-40% GPU while MC encoder set to OpenCL shows high 90s CPU & 0 GPU. Running a 2600K with Virtu on or off, no difference -- I did not try disabling the Intel OpenCL.

I thought that with an SSD nowadays you did not need to do anything to them. As for optimizing background services????? Can you explain?!

Pushing the blame onto nvidia does not help this matter. Here is why....

V11 with the latest nvidia drivers on the same system works with ram preview set 512. V11 becomes less stable as the ram preview setting go higher.

V12 same system same nvidia driver stutters when preview ram is set to anything but 0.

Boris Red on the same system & same drivers: ram preview works.

After Effects same system same drivers: ram preview works. (This is an outdated version of AE yet RP still works with the latest nvidia driver.)

V12 ram preview is bugged.

Fact: many users of v12 now set their RPS to 0 to stop crashes & stuttering.
This makes ram preview unusable in v12 unless the user is willing to go back & forth between this buried setting. The history of Vegas shows it has always had problems with the RPS. I have a feeling that the NBT problems are related to memory handling in Vegas & are more a Vegas problem than NBT.

I'm sorry if this problem makes people leave the forum. This is not my intention.
Vidmus, sorry for the assumption, but why do you behave like this? I can't fathom your behavior. Why are Vegas bugs taken so personally? We all want a more stable Vegas & we are on the same side. We just go about it differently with the focus on different concerns.

I appreciate everyone on this forum & thank you all for reading about my concerns. I will be more polite in the future & will not make general accusations & insults anymore. Please have a wonderful, loving day.

@Lovelight,

I have been feeling extremely down lately. Sorry!

Seems that I think I have this whole crazy thing figured out then something throws a monkey wrench in it.

I can say that Vegas works on my system without crashes but does it really?

If I were to use the same media and/or workflows as others would Vegas still be stable on my system? Maybe or maybe not.

Most of the problems seems to be focused on the use of GPU. Maybe if SCS would have not chosen OpenCl and went solely with the GPU itself things would have been better? With the use of preview memory and the system timings for sending bits to and from the GPU I think it would work up to a point and then get all clogged-up

With the latest drivers and rendering to uncompressed AVI I watched the task manager and at a certain point the rendering would not only gradually slow down but the CPU use would also go down and then the render would stop and the CPU use would go down to zero. It was as if the system was getting more and more clogged-up as it went. There are better tech terms for this but I am too tired to think of them at the moment.

Even with the 296.10 driver there is a gradual slow down as the render progresses but not to the point of stopping altogether. This on a two hour video.

Changing the preview ram to zero affectively turns off GPU when it comes to increased performance on my system.

Preview ram an old way of doing things with Vegas that is apparently not totally compatible with GPU use especially when it comes to certain types of media's.

Then again, another wild guess?

Vegas works on my system and with the media and workflow I use and not others. WHY??? All I am trying to do is help others find out why. When someone bites me for it I get burned out and no longer care and want to just leave.

I understand the frustration for those who are having difficulties but why bite those who are trying to help?

It does not help when the one who gets bit is feeling way down at the time either.

I will put all of that behind me now.

So what can WE do to either solve these problems or at least significantly reduce them?

What can WE do to help SCS solve the problems?

AND WHAT CAN SCS DO TO HELP US SOLVE THE PROBLEMS?????

AND WHAT CAN SCS DO TO SOLVE THE PROBLEMS?????

For one, SCS can put a REAL moderator on here that is helping us on a daily basis and not just drop in once in a blue moon! They can act like the actually give a D-A-M-N about Vegas users instead of this once in a great while visit to this forum!

As for us, we need more civility and to stop biting each other.

ok, Next...

Most sincerely,
Danny Fye
www.dannyfye.com/ccm

No way. The new build can't render mov file. When I touch the "Personalizar plantilla" button (I use the spanish version) Vegas frozes for ever. Back to 486.

Erni

>>>"So what can WE do to either solve these problems or at least significantly reduce them?"

We can't really "solve" anything except for installation quirks and such, with a knowledge base of "internet wisdom". We don't have the source code.

It is possible to come up with workarounds that can get someone by until a fix arrives. For example, the preview ram zero setting workaround. Vegas is obviously using that for things other than RAM pre-render and it changes/shows/"fixes" quirks and bugs.

>>>"What can WE do to help SCS solve the problems?"

Do something more than bitch, it does not work. They should fix their stuff, and so on. Since the days of BBS's the net has been a bitch session.

Few things are ever 100% out of the box failures. For example, the color match item quoted in this thread. This means it works, but has situations where it does not work.

You can't fix something unless you have something that reproduces the issue, PRECISELY. This ain't horseshoes. Close does not cut it.

For me, with my bug report of a GPU crash in playback of a slideshow with crop/rotate/zoom, I created a project that reproduced the problem on my machine and made that available to them. It was a 900MB zip file do to the size of the sources (jpegs). The lockup is very random so I made the project long enough hoping it would help them since their machines are not exactly like mine.

Will they ever reproduce and fix this? Who is to say. I know did my part.

Heck, it certainly could be a driver issue, in which case they can only beat on AMD and/or Nvidia to get their act together.

>>>"AND WHAT CAN SCS DO TO HELP US SOLVE THE PROBLEMS?????"

Have intelligent support that does not operate off a script.
They can be responsive with trying to isolate possible bugs. I have basically gotten no response and I have been pedantic as hell with information, trying to test, reduce, isolate things before I ever report. Basically trying to pre-answer their script support BS, and get to the center of the issue.

They can possibly provide stuff on the internal preferences we can enable/disable to workaround, identify issues.

Take for example GPU use. Internal prefs could let you disable only some items, if possible. This can give a workaround and maybe a diagnostic of the source of the problem.

They can also have diagnostic log info output. If they cannot duplicate on their machine with your example reproducible project, then try getting diagnostic info from your machine where it is failing.

AND WHAT CAN SCS DO TO SOLVE THE PROBLEMS?????

Actually respond the valid legitimate reproducible bug reports.

With the whole GPU thing, too often it is very difficult to reproduce something. Sometimes you never can. It has happened to me. No matter the diagnostic and other stuff, some things are too sporadic and customers unwilling to help.

@ VidMus: "Maybe if SCS would have not chosen OpenCl and went solely with the GPU itself things would have been better? With the use of preview memory and the system timings for sending bits to and from the GPU I think it would work up to a point and then get all clogged-up" -- "Vegas works on my system and with the media and workflow I use and not others. WHY???" -- "AND WHAT CAN SCS DO TO SOLVE THE PROBLEMS?????"

Purely FWIW, when it comes to graphics hardware acceleration developers can either turn to proprietary methods like CUDA, Stream, & Quick Sync, or use an open solution -- OpenCL -- for everything. Both have advantages. OpenCL works with everything -- at least in theory :) -- so it's hardware agnostic & you get the largest user base. It's also simpler to use one method, OpenCL, than 3 -- Adobe solves the problem in some of their stuff by choosing CUDA & ignoring AMD/ATI & Intel. Sony Creative might also have ties to AMD, e.g. from working together in the past, & AMD/ATI has moved on from Stream to embrace OpenCL. From a user standpoint OpenCL may be superior because it allows you hardware freedom. I just bought a new graphics card, choosing AMD/ATI because it has better OpenCL benchmarks [http://clbenchmark.com/] -- there are also differences in quality with the video processing, but IMHO info's a bit hard to come by, often irrelevant to apps like VP, & often subjective, so I'll leave that alone. If I relied on Adobe [or other apps using CUDA] I wouldn't have had that choice. [I actually would have preferred Nvidia, but with all apologies to any Nvidia fanboys, this time 'round everything I've read says OpenCL is where their current crop is lacking]

As far as things "getting clogged up", I think that's a decent enough way to put it. A developer has to identify which operations can be performed faster with a GPU, & then figure out how to split those off & send them to the GPU, all without timing issues -- it doesn't do much good if the GPU does whatever at lightning speed, only to have the results sit there waiting for the CPU to be ready to accept them. Making it more complicated, higher end graphics cards are faster in that respect than cheaper ones, just like more expensive CPUs are faster, so a developer has to [or should] account for what happens when the user has a slower/faster GPU & CPU. Then there's Windows, which adds it's own constraints, & the fact that graphics hardware is so complicated nowadays that there have been & are problems both Nvidia & AMD/ATI can take many months to figure out what's happening. Finally, graphics hardware assisted video processing is an ugly stepchild to graphics card marketing folks -- their prime target is the gamers buying 4 $500 cards -- so both development & fixing related problems sits semi-permanently on the back burner.

As far as why this stuff works for some & not others, IMHO it helps to think of the PC/laptop as a sort of ecosystem. In nature the introduction [or extinction] of the smallest organism can have outsized effects on everything else. While most everything hardware is standardized, there are small variations, even among the same brand & models of motherboards, power supplies, graphics cards etc. The example that comes to mind [of what those small variations can mean] is overclocking -- how far you can go depends on the individual CPU/motherboard &/or graphics card & how efficiently it operates... I think that's one reason they compare benchmarks on-line, i.e. mine's better than yours -- if everything was identical why bother? It seems logical that the same sort of variations apply to OpenCL performance. Another factor is what software's installed -- Windows' Direct Show can be a nightmare. Take for example a DS filter that's called or opened whenever a video file or type of video file's opened, & then consider what happens when it has some incompatibility with the graphics card driver set, delaying or maybe breaking one or more of it's functions, or maybe a DS filter or part of another driver set conflicts with whatever app. I use Virtu, which routes some graphics stuff to the CPU's built-in graphics to take advantage of Intel's Quick Sync -- I have ffdshow along with some other stuff installed & set to use Quick Sync for some video formats, which can speed some things up. In an earlier version of VP 12 the Intel OpenCL driver caused issues -- I had to disable it temporarily when I used VP -- & I've yet to see what the effects are from the LAV Filters with this latest version -- in the past VP 12 didn't like them at all, so again enabled/disabled them depending on what I was using.

What can SCS do to fix this sort of thing? Three words: Spend more money. There's little that can't be fixed if enough resources are thrown at it, but the problem is who provides those resources. They could charge more, & the extra profits would allow them to hire more people along with buying more hardware to test VP12 on, but then you have the problem of if they charged more, would their customer base shrink so that total profits decreased instead? Now I know it's common & popular to blame greed when a company doesn't spend more money developing/making a product, & *maybe* parent Sony is partly to blame, but we VP12 users aren't going to influence a company as big as Sony, so I consider the point moot.