Good luck. [;)]

DG

david it seems i managed to screw up the machine during some tests and am finally in the boat with you :-/

unfortunately i noticed this too late and can't reproduce the step where this issue happened now.

there is no time left for playing around this week so i have to ask you for some more patience ...

christian

edit: you won't beleive it .... it seems the issue is related to corrupt sample data (a sector from a harddisk fails or similar)

solution: open directory manager, remove all content, add some content

(you should notice the memory is increasing to 800 MB only opening the DM without having any VE opened before)

reboot - open VE ... back at 300 something ... (thx to george for the clever idea)

after adding the corrupt data the effect returns ... isn't that weired?

now we just need to find out what affects the taskmanager to show this amount of used memory even without any process listed ...

probably it is less timeconsuming top find which collection contains the corrupted data than to re-install all, the one which is found to be responsible for the issue i would re-copy or re-install of course.

christian

you forgot to reboot between 2) and 3) .. otherwise you wouldn't free the memory and see ... nothing ...

;-) of course you only need to reboot (maybe log off / log on is enough) if the memory goes up again more than normal ...

Hi cm,

Here is my feedback:

I cleaned out the DM and rebooted. Checked my Committed RAM in TM with nothing launched, its 225mb. Opened the DM, FireFox so I can type this, and the TM.  Lastly I open the Windows Explorer. My Committed RAM at this point is 253mb.

Now, I drag and drop the VSL Percussion data folder of the Cube into the DM from Explorer. This folder is 51.3gb. My Committed RAM jumps to 357mb, thats 104mb. Normal? 

Now, I will reboot and re-open the DM and do a scan and see what happens.

I will edit this post when I'm back up...be back in 2 minutes. 

Ok, I'm back.

Launched TM, DM, and Firefox. Committed RAM is at 257mb. Only Percussion data is in DM. Clicking Rescan...Commited RAM jumps up to 358mb, pretty much the same as before.

I'll add another data folder to the DM with the Percussion already there, this time Brass II which is 39gb. Committed RAM goes up to 441mb, thats a rise of another 83mb. 

Adding Orch Strings II 18.9gb, now RAM jumps to 473mb, another 32mb.

I'll finish off this drive and add the WoodWinds II which is 44.8gb, now RAM is at 546mb, a rise of 73mb.

So I started with 225mb with nothing launched. Added Percussion, Brass II, Orch Str II, and WW II to the DM. Total of 154gb of data and my Committed RAM rose to 563mb, thats rise of 338mb. That can't be normal, right?

If we minus the RAM it takes to run the DM we wind up with a Commintted RAM of 554 so its 329mb of vanished RAM.

When I close DM the RAM is not released. I have to reboot to get it all back.

One thing I did not mention is that I have previously loaded only one volume at a time into the DM and rebooted to see if one of the volumes was the problem. After checking and noticing the RAM was still jumping up is when I decided to write this. 

This is driving me nuts!

Any ideas?

Like I said, the data files were copied from another computer to this one via ethernet. My other computer is a WinXP32 system that is now no longer used. I guess all my data could be corrupted from the copying but I bought the Vienna Bosendorfer recently and installed directly to this machineand I have the same problem with that as well.

All my VSL data is spread across 3 internal seagate drives and no matter which drive I use to drop data folders in the DM the RAM goes up like this.

What should I do?

I'll try anything.

David

keep in mind i only proceeded as described above to return to *normal behavior* ..

although before i uninstalled LCC, VI, VE because i assumed the problem here.

uninstall always means here a clean uninstall from control panel - add/remove software making sure no processes are running followed by a reboot.

bad RAM is no probable reason IMO, you would rather get *could not read* or *could not write* at adress 0x1234567 or something similar.

a failing harddrive (loosing and incompletely re-assigning sectors) would be a possible reason though.

christian

 I hope no one forgot about me.I'm still having this vansihing RAM problem.

I installed Vista-64 thinking it would show some more info than XP64

or it would behave differently but its the same with one change.

It does the DM scan once the system has booted to the desktop!

Why in the world would it do that?

Weird thing is that if I turn virtual memory on it does it when I run

the DM but when I turn VM off then the RAM vanishes right after

bootup, within a minute.

Is there some sort of Indexing or database being built? 

David

david, unfortunately i don't even understand this statement

@DM33 said:

It does the DM scan once the system has booted to the desktop!

earlier i reported that i don't like VISTA because it starts with 680 MB memory usage on a *naked* system, which goes down after some minutes to ~ 320 MB (VISTA 32 on a 2 GB machine here) - on the same machine XP32 with an unhealthy amount of applications installed starts with ~ 260 MB memory usage.

i'd assume VISTA 64 behaves similar and moves some of the memory used at startup to the virtual memory area (if activated only of course)

btw: have you already found which collection has been responsible for the excessive comit charge? here it have been the solo strings ...

christian

ps: i just noticed the ADD FOLDER in the Directory Manager is working recursive now on XP64

Hi cm,

Sorry, that statement was meant to say "Does the DM do a scan once the system has booted up to the desktop?".

On Vista64 it was doing just that but it was the Vista SuperFetch function. I disabled it and that issue went away.

Unfortunately my vanishing RAM problem has not gone away.

I have done a reinstall of WinXp64, hated Vista. I have also chk dsk'ed all my drives and tested my RAM chips for errors and found no problems, everything is fine.

For testing I rebooted the system, launched the TM and VI, and the RAM shot up just like before. It did not go up as much as before but I only

have 1 volume installed with 12 to go.

Copying Orch Str I as I write this and will install that ASAP.

Will report back to you.

BTW, I have optimized this machine as I do all my machines but this is the first time I'm using WinXP64. Do you think the optimizations have anything to do with my problem?

Here is the list of optimizations:

http://www.musicxp.net/tuning_tips.php

Let me know what you think or what I could try next.

Can you explain what SHOULD be happening in regards to RAM when I launch the VI?

How much RAM should the VI take when it launches and does a data scan for on an Extended Cube system?

Mine seems to take a GB of RAM. It did not do this on my WinXP32 system.

David

P.S. - Just finished installing the Orch Str I volume. Rebooted. Only have 2 volumes installed: Chamber Strings and Orch Str I.

On bootup Commit Charge was at 210mb, after launching VI, not VE, my Commit Charge went upto 416mb. When I close VI

it only comes back down to 370mb. Why not back to 210mb? 

david, reading you mentioned optimization according to musicXP i decided to not continue because of lack of time.

however i just ha´d a look on their reworked site and found many of the tweaks i thought to remember (a series of registry hacks) have luckily disappeared.

as a sidenote: i don't understand *Turn off System Restore on all Drives* - i would rather be happy if system restore is active on my system drive, although i also switch it off on all audio drives ... anyway

we can't get the few XP64 systems we currently have available to behave as you describe, so there is nothing to investigate and report unfortunately .... the short intermezzo as mentioned above was immediately gone after removing the corrupt sample data.

if you find the time please check out the famous sysinternal tools and keep us updated if you notice something suspicious

http://www.microsoft.com/technet/sysinternals/Processesandthreadsutilities.mspx

christian