Vegas mxf handling deteriorating

megabit wrote on 2/7/2010, 3:33 AM

Guys, looking at many posts on weird problems like memory leakage or green/red/black frames in Vegas Pro (v. 8.0 and 9.0), I considered myself lucky as I had never suffered from them.

Until a couple of moths ago, when - for the very first time - I noticed memory leakage when smart rendering my EX mxf clips (35Mbps 420, 1080/25p to be exact). In fact, when a project is long enough it will never finish rendering as at some point, all RAM is consumed (8GB of it) and heavy trashing to swap file would freeze the whole system before the smart rendering is done. All other formats (like HDV) are OK. I never actually resolved this issue (neither did SCS whom I asked for support) - but hey, how often do you smart-render a long project? So, I just lived with that.

But today I noticed the very same thing happen when just playing back mxf timeline - if long enough, playing from beginning to end will result is system crashing due to exhausted memory! At first I thought it's just my 100 Mbps 422 clips from nanoFlash that are causing this - but no, same happens with the EX ones. And only in v. 9.0 (both 32 and 64bit) - no such problem in v. 8.0...

Strangely enough, the nanoFlash clips all start with a single green frame - though that's in v.9.0-64bit only!

What's even more weird, Vegas freezes more and more often at the splash screen saying "Creating file I/O manager" . Kill it, and launch again - it will usually start OK (so far).

So, what I'm experiencing is a definite Vegas performance deterioration - at least when handling any flavor of the long-GOP mxf files.

I'm not here to rant or vent - just a question before I do a fresh Vista installation (which I'd like to avoid, as otherwise, my current installation has been working perfectly for me):

- any one experience the same problems with mxf files? If so, any suggestions as to the culprit here? Thanks in advance everyone,

Piotr

Comments

megabit wrote on 2/8/2010, 2:47 AM

Bump!

- anyone?

PS. I forgot to add that it's only the combination: mxf clips/Vista OS. No such thing happens with mxf under XP, or any other format under Vista... What's more, it's the same on both my machines (desktop: Vista x64 / laptop: Vista x86)

farss wrote on 2/8/2010, 4:04 AM

I'm not seeing your problem and I'm not running under Vista. Staying with WinXP down here until I have a compelling reason to change. In fact a lot of my paying work is done under Win2K.
Your problems only serve to justify my reasoning.

Bob.

Jay Gladwell wrote on 2/8/2010, 4:38 AM

Sorry to hear you're having these issues, Piotr. That has to be frustrating.

I'm running under Windows 7. So far I haven't had any such experiences--yet. I went from XP to W7 (by some infelicitous circumstance) and bypassed Vista. Had such not been the case, I would still be running XP.

Hope you find the leak and get it plugged!

EDIT:

"What's even more weird, Vegas freezes more and more often at the splash screen saying "Creating file I/O manager" . Kill it, and launch again - it will usually start OK (so far)."

I was experiencing this big time under XP! Since I moved to W7, Vegas now loads within seven seconds--every time!

megabit wrote on 2/8/2010, 5:31 AM

Bob and Jay - thanks for the answers.

Interestingly, I just run a test on my Daughter's laptop with Windows 7 64bit, and everything runs great! No memory leaks whatsoever - neither at smart render, nor at playback of mxf timeline.

One would be tempted to curse the poor, old Vista again - but for over 2 years, I didn't have these problems under Vista, either.

Must have been some of the many MS patches, or perhaps my application installations that has driven it south. My most suspicious candidates are:

- Sony's own XDCAM Viewer (as it deals specifically with the Sony's mxf format)

- Vista codecs package v.528 that I installed on somebody's advise here that it can improve wmv rendering in Vegas.

I tried to get rid of both, but - as you know - packages like this never uninstall clean... So, I'm facing the OS fresh installation - bummer.

;)

Piotr

PS Jay, I disabled XDCAM Explorer in Vegas - no joy :(

Jay Gladwell wrote on 2/8/2010, 5:51 AM

"... I disabled XDCAM viewer - no joy :("

This is another of those many instances where I must plead total ignorance. How might XDCAM viewer cause a memory leak?

megabit wrote on 2/8/2010, 6:02 AM

Jay - I guess it couldn't. I tried to eliminate the "creating file I/O" splashscreen freezing, but it didn't help.

What I just found out however, is that when the freeze occurs, Task Manager shows some left-over of the previous Vegas session that crashed / froze due to the memory leak (either the Vegas.exe, or FileSurrogate.exe *32 process). So in my case, there is some indirect connection between the two problems.

farss wrote on 2/8/2010, 6:26 AM

I know I'm stating the obvious but damn it I cannot resist.
By your own observation the problem is somehow tied to running Vegas under Vista. Why persist with Vista, either go forward or backwards. Going back to XP seems very sensible to me. I do like Win7, I for once like the bling and it does run nice on our new laptop. Still I'm in no hurry to start running Vegas under Win7.

Bob.

megabit wrote on 2/8/2010, 6:53 AM

Bob,

Good point - as always:)

However, I do have good reasons (at the moment) to stick with Vista x64:

- XP: no support for x64 (and apart from Vegas x64, I MUST use lots of RAM for the 64-bit version of Moldflow - my main CAE application)

- W7: need to recover from my difficulties you know about before I can afford buying the highst version (possibly along with a new machine, as Moldflow flies with CUDA).

Piotr

PS This is my post No. 1,000 here - celebrating ;)

jabloomf1230 wrote on 2/8/2010, 7:36 AM

"This is another of those many instances where I must plead total ignorance. How might XDCAM viewer cause a memory leak?"

I really doubt that the XDCAM viewer could have any effect on Vegas, since the viewer uses the Windows DirectShow interface to decode the video from an MXF file and Vegas uses it's own built-in codecs and filters.

megabit wrote on 2/9/2010, 5:26 AM

OK guys, so my patience has expired after - answering my e-mail support request - SCS instructed me to remove non-essential processes from my Vista installation(s) in order to rectify the problem. Here is what I answered to their instructions:

" Dear Eric,"

Yes I know I vented / ranted this time, but - after a long time of patiently asking for help - this is the only way to get it at last?

- let's see...

Piotr

Jay Gladwell wrote on 2/9/2010, 9:25 AM

Piotr, I know how frustrated you. I'm sorry this is happening to you.

For me, the worst part of experiences such as this is the "canned" response we get from the various support teams.

(<sigh> I sure do miss the SF days.)

john_dennis wrote on 3/6/2010, 10:38 PM

Potentially irrelevant observation follows, ignore at will.
I'm running Windows 7 and Vegas 9.0c and haven't experienced your problem, but I noticed this morning that the "FileSurrogate.exe *32 process" was running during a render. It sure looks like a 32 bit process to me. Am I wrong? I suspect that 32 bit I/O processes are probably adequate to run I/O (if that is in deed what it's doing). If it is a 32 bit process, then maybe the conversion to 64 bit is not complete.
End irrelevant observations.

megabit wrote on 3/7/2010, 1:38 AM

Funny you would mention the FileIOSurrogate process just now, John.

It so happens that I'm still exchanging emails with SCS Tech Sup on the matter, and they asked me recently to try and pinpoint the offending process.

It turns out that in Vegas 9.0c -64 bit, it's the FileIOSurrogate.exe*32 process that never releases memory when playing back or smart-rendering mxf timeline. Its associated memory hard faults counter - as observed in the Performance monitor - goes up at the same rate as the RAM usage (the latter being some extra 0.1GB each second).

BUT, with the 32bit version of Vegas 9.0c, it's the vegas.exe process that does the same!

john_dennis wrote on 3/7/2010, 7:09 AM

I was looking at the Performance Monitor during the render trying to determine what process was using the cpus. I was surprised to see FileIOSurrogate.exe*32 was using much more than vegas.exe. I suspect it is doing more than just I/O for an MPEG-2 render. Still, this may be tourist information considering that in the 32 bit version vegas.exe fails. But, the offending module could have been moved from one process to another depending on the version. Everything I say should be considered pure speculation.

megabit wrote on 3/7/2010, 7:19 AM

This observation of yours I cannot confirm, John - on my system, when rendering, it's always the vegas.exe process that uses most of the CPU resources.

john_dennis wrote on 3/7/2010, 9:57 AM

I'm rendering to mxf right now and FileIOSurrogate.exe*32 process is running about seven to one compared to vegas.exe on Windows 7. CPU is running around 90% and physical memory is holding around 30% of 6 GB.

0 Hard Faults/Second