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

@ktnujynisis said:

Im still having the exact same issue. Mine is pretty severe. Sometimes I'll can start off with 1gb missing before I touch anything. Give me a week, I'm gonna show the screen shots. And I am using a Mac Pro

So what does that have to do with XP64?

DG

possibly ktnujynisis is running XP64 on a macPro? the mac people here don't allow me to do so ;-)

@ktnujynisis said:

same problem... different OS. Which obviously disconnects the problem to the operating systems or he OS's type.................??????????????!!!!!!!!!!!!!!!!??????????!!!!!!!!!!!!!!!!

@DM33 said:

I'm wondering why its only happening on so few systems.
Only a couple of people have mentioned the problem.

I would think it would be a bigger problem. It must be something
wrong with our specific systems. May RAM type or bad RAM or errors
on the hard drives.

David

@DM33 said:

VSL seem not to be able to reproduce it this problem. The one time they experienced it it was traced to a corrupt solo strings folder.

james, david: apples and pears .... while david reports to loose 800 MB in commit charge just by opening the VE you tell us abot (loosing?) 32 MB when loading solo strings.

i wrote, that i could fix a similar issue david had removing a collection with obviously corrupt data.

some mac guys tell us they notice increase of the _inactive_ memory (i posted already a link to what inactive memory is) - so where is the common denominator?

sorry, either i'm too blind to see it or there is none.

each operating system has some sort of memory management which can in mosT cases not be detirmined by an application.

i would exclude reasons like chipset, memory, processor (except it is really faulty of course, but this would be another story) - more interesting would be *features* like pre-fetch, running services, pagefile settings and this kind.

see the thread about XP giga and memory management: defined situations give defined results, and even those differ between identical machines sometimes. we should choose a more systematic approach, because you have to know i'm not the engineer responsible for setting up your machines guessing your details - i can run a defined series of test on the few machines i have under my control and we can discuss issues, ideas and solutions here.

thx, christian

ps: of course a screenshot with all relevant information from activity monitor/taskmanager helps ...

david, is it still the same issue we started talking about (commit charge increases, but we don't see any process listed using it)?

i had this too for a few hours but have not been able to get this (mis-)behaviour back so far ...

christian