The issue seems to be that vegas is committing the clips to RAM so they are paged via the paging file... so for each clip you load the space is reserved 'in ram' depending on the total clip size... the thing is, the file is read in from a paged disk file anyway so reserving ram for it is not required... well maybe if you start to do things with it, but normally no reason to copy it.

The project I am working has around 100 clips of variable size... I have 64Gb of real RAM and have had to create a VM page file of 150Gb giving me 216Gb of 'pageable' RAM - I can only ever have 64Gb at a time, but the VM makes it appear as though I have 212 to play with... So, if it was really paging, I would expect to see the paging file used as it flipped the 'excess RAM' (which I have had to allocate) in and out of memory. The project has actually committed 106Gb so if it were actually used I would expect the 42Gb (106 - 64) to be paged and visible in the task/resource manager - but its not, the paging pool is 800Mb!

You are correct that increasing the VM makes the problem go away, but it also means you effectlivly lose that much disk space for no gain...

You are correct that increasing the VM makes the problem go away, but it also means you effectlivly lose that much disk space for no gain...

That was only for a trial
This can't be the solution

I thought I would test this on Windows 7 Professional while I'm running the Vegas 14 trial. I loaded 269 (over 3 hours) AVCHD files on to the Vegas Pro 14 timeline and watched the memory usage climb. I never experienced an "out of memory" error although that's not the way I would usually like to work. I have 16GB of memory and I let Windows manage paging on my SSD only.

Just because I'm easily entertained, I added .MOV files until even I got bored at almost 7 hours on the timeline.

But did you do anything with it? E.g. try to render? Or save that project and re-load it?

That's when I get the memory problem: loading a previous project. Or try to render a project that was just created.

I can put any amount of clips on timelines but I cannot do anything with them, not even re-load the project.

did you look at the memory usage in task manager to see whet the commit level is... mine is now 106Gb / 216Gb... thats after the VM increase. Previously it got to 64Gb/64Gb and thenexpectedly it crashed

"But did you do anything with it? E.g. try to render? Or save that project and re-load it?"

I saved and reloaded the project. It then failed. Sorry, can't show the condition of the machine but Commit (GB) was around  62 GB. I added a 16.7 GB pagefile to one of my spinning disks and the project opened again.

"did you look at the memory usage in task manager to see whet the commit level is... mine is now 106Gb / 216Gb... thats after the VM increase. Previously it got to 64Gb/64Gb and thenexpectedly it crashed"

Yes. I appeared to have a similar threshold ~64 GB. Taking the cap off the pagefile appeared to give the O/S and Vegas some head room. I generally don't allow the O/S to use spinning disks for paging because I change boot systems often and they leave files on the disks after the system has changed.

The potential for failure appears to exist on Windows 7, too.

The fact is that VP13 never used so much memory

the max. commit level of VP13 in this example (win10) is about 2GB!
the max. commit level of VP 14 in johns example is about 35 GB!

When I did my test, the memory usage never went beyond 20% of use. The commit charge went up a very small amount. I had a project with 4k videos that was 1 hour and 45 minutes in size. And that included some FX's.

I have Windows 10 and it is set let Windows "Automatically manage paging file size for each drive". C: is system managed. V: is set for none. Both drives are SSD.

In the past I have seen all of the tips, tricks and suggestions for how to set Virtual Memory and have tried them all only to have problems once I do. So I let Windows do its default thing and leave it alone. No more problems!

So if what I do does not work for someone else then maybe there is another issue of some kind.

So, as far as my system is concerned, this is not a bug in Vegas 14. Vegas 14 is exposing a problem instead of being the problem!

The problem is data dependent.
I have no problems with about 4 hour HD mp4 files (commit level max 1.6, loading time 1 sec)

The Quitter appears to be correct that the Commit (GB) differs significantly between Vegas 13 and Vegas 14.

I created a project in Vegas 13 that is 6 hours 40 minute long containing 307 AVCHD files. The Commit stayed around 3 GB as I reopened and played the timeline.

I opened the same project in Vegas 14 and Commit climbed to 78 GB. Few people have that much memory, so page file management appears to be critical. 

"So, as far as my system is concerned, this is not a bug in Vegas 14. Vegas 14 is exposing a problem instead of being the problem!"

I dont believe this is correct... the decision to allocate memory and more importantly how to allocate and manage it is made by the programmers... it appears something has changed in vegas to make this more of an issue (maybe the type of memory mapped file allocation), so I believe it is a Vegas problem. Potentially it could just be an oversight in which case it may also be a simple fix.

It would be good if Magix could at least provide an insight as to whether this is expected or indeed a bug...

A program should take a system limits into consideration and at least handle reaching those limits :)

Over the years I used suggested settings for the paging file, everything from setting the minimum and maximum, to none at all. I ALWAYS had problems of some kind when I did! I did not have problems with every project and file types, but I did have problems.

When using the NB Titler and trying to make a credit roll, the Commit Charge would run all the way up and hard crash the system in 15 seconds. So unless I stopped it real fast, I would lose the entire show. I did not have this problem with other projects I used with NB Titler.

When I changed the settings to let Windows automatically handle the paging file, I no longer had any problems.

Letting Windows handle the paging file has solved many problems including some very strange and illogical problems for me. So you can take all of those other suggestions for handling the paging file and throw them in the trash can as far as I am concerned.

With all of that, maybe there is still a bug in Vegas 14? I do not know but at least it works for me.

I cannot afford to upgrade at this time so as far as I am concerned this does not mean anything to me at this time. I cannot understand why anyone would upgrade at this time anyway. The real costs will be $249.95 plus the upgrade costs of Vegasaur if one uses it and then if one needs Plural Eyes then one has to use Vegas 13 to start the projects with. And then the AC3 Pro nonsense, Vegas Pro 14 is NOT ready for prime time or being upgraded to!

Oh yea, it plays back much slower because it does not support my 580 card. Note: I did get faster playback with the Intel Graphics but one of my monitors input went bad so I to change things which required a reinstall of my 580 card.

Anyway, I will stick to Sony Vegas Pro 13 for now while you guys beta test Magix Vegas 14. Or is that really Magix Vegas 13.5? On Magix I left the ‘Pro’ part out on purpose.

Yes, only what MAGIX has to do is to update the System Requirements:

Operating system: Microsoft® Windows 7 (64-bit), Windows 8 (64-bit) or Windows 10 (64-bit)

Processor: 2 GHz (multicore or multiprocessor recommended for HD or stereoscopic 3D; 8 cores recommended for 4K)

RAM: 4 GB RAM (8 GB recommended; 16 GB recommended for 4K)

Hard drive space: 500 GB hard drive space for program installation and pagefile using; Solid-state disk (SSD) or high-speed multi-disk RAID for 4K media, recommended to provide from application or system crashing

Whow, it can be so easy😉

Yes, only what MAGIX has to do is to update the System Requirements:

Operating system: Microsoft® Windows 7 (64-bit), Windows 8 (64-bit) or Windows 10 (64-bit)

Processor: 2 GHz (multicore or multiprocessor recommended for HD or stereoscopic 3D; 8 cores recommended for 4K)

RAM: 4 GB RAM (8 GB recommended; 16 GB recommended for 4K)

Hard drive space: 500 GB hard drive space for program installation and pagefile using; Solid-state disk (SSD) or high-speed multi-disk RAID for 4K media, recommended to provide from application or system crashing

Whow, it can be so easy😉

Well, it is not that easy. I meet all of your suggested specs and I still have the memory problems!

it was only a joke

This link is very informative for those who are intrigued by how memory is

Particularly, this paragraph:

"An important word there is “could.” Windows establishes a “commit limit” based on your available physical memory and page file size(s).  When a section of virtual memory is marked as “commit” – Windows counts it against that commit limit regardless of whether it’s actually being used.  The idea is that Windows is promising, or “committing,” to providing a place to store data at these addresses.  For example, an application can call VirtualAlloc with MEM_COMMIT for 4MB but only actually write 2MB of data to it.  This will likely result in 2MB of physical memory being used.  The other 2MB will never use any physical memory unless the process reads from or writes to it. It is still charged against the commit limit, because Windows has made a guarantee that the application can write to that space if it wants.  Note that Windows has not promised 4MB of physical memory, however.  So when the process writes there, it may use physical memory or it may use the page file."

My considered opinion for developing a "workaround" for Vegas 14, Build 161 behavior of commiting files to memory is based my experiments and Microsoft documentation.

See this article for Windows 8.1 and below. (Windows 10 probably has the same constraints, but I haven't verified that possibility, yet)

How to determine the appropriate page file size for 64-bit versions of Windows

The following table lists the minimum and maximum page file sizes of system-managed page files.

From this table I would expect the maximum size of my pagefile per disk (drive letter or partition, not physical disk) to be 3 x 16GB=48GB. I actually observed that the pagefile on my system disk stopped growing at 49,351,044 MB. You can observe the same by watching the following video.

Notice when the system partition pagefile stops growing and the pagefile on a different partition on the same SSD starts to grow.

BIG NOTE:

It matters not how big your system disk might be or how many drives on which you place a pagefile, the pagefile on a partition or drive letter won't go over 3xRAM for System Managed Pagefile. So, if you're booting from a 1TB SSD, only using a few hundred GB, letting Windows manage the size of your pagefile and you're wondering why you're running out of virtual memory, that's probably the reason.

With my 256 GB SSD, I decided to Shrink the Volume and use the resulting unallocated space to create a Simple Drive (Letter Z) and let Windows 7 Manage the Pagefile. There is no point in making that partition more than 3XRAM, though. If you still need more pagefile space, 1) Manage the size yourself with the minimum equal to 1XRAM plus a few hundred MB and the maximum equal to the maximum amout of space per disk that you're willing to devote to having it used for this effort (a.k.a. Whatever will keep Vegas 14 working without crashing). 2) Shrink the Volume again and repeat or spray the pagefiles around to all the big spinning disks that are inside the system.

Please don't interpret my efforts here as being an appologist for the Vegas coders. It's clear to me they changed the way the program deals with memory from Vegas 13 to Vegas 14, whether deliberately or by "accident". I'm quite agnostic on how coders code. I'm just proposing a way for the rest of us to get the video out the door.  

3x 8 GB Pagefile = out of MEM 😶

I can only put more files on the timeline before the run out of memory, but it runs out

Do this: (More likely to work reliably if you have 16GB or more of real memory.)

Or this: (With <16GB of real memory, manual virtual memory management may be the only workable option.)

If you have the disk space, it'll work.

system managed: out by 15.5 GB, System new startet before

i know if i used 100 GB Pagefile it will work, but is this the solution?

As John Lennon said, "Whatever get's you through the night."

John Lennon is dead, isn't he?
VP14 is on the best way...