Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jeh14]

What on earth is causing MC 12 to need a "Commit size" (this is process-private virtual address space, e.g. heaps and stacks and so on) of OVER ONE GIGABYTE?

All of the files together in my library directory -- i.e. all the info MC needs to construct the displays (I have thumbnails turned off) -- total to less than 10 MB!

This is causing some severe performance problems on my machine. I have 2 GB RAM, and Vista normally allows the working set (actual RAM valid for the process) to run up to a bit over a gigabyte. But every now and then Vista needs the RAM for something else, so it does a working set shrink down to 20 MB or so.  Then when I alt-tab back to MC, MC has to fault all that stuff back in... ugh.

I never saw this issue with MC 11.  Please note that while some aspects of the working set adjustment, etc., are new with Vista, the commit size is not: This is something the program is doing, by allocating massive amounts of heap or something similar. The operating system doesn't do that on behalf of programs.

( Er, well, code in an OS-supplied DLL can allocate heap, and many of them do. But those DLLs are shared by just about every process in the system, so we'd be seeing ths problem in many other processes if the bug was in a system DLL. )

Is this perhaps addressed in the new version posted today?

Please don't tell me to scrag my library and re-import all my MP3s (about 21,000). It's not that the import itself is such a bad job, but I am really very tired of having to re-establish all of my custom fields, custom views, podcast settings, etc., after a library rebuild.

[jeh14]

Addendum: This is not a memory leak in the usual sense, as those usually involve an ever-increasing amount of virtual memory allocated. 

It is definitely associated with the library.  Switching from my normal library to the "default" library (which has been cleared) cuts the commit charge to only about 25 MB. 

[JimH]

MC will be slow until your thumbnails are built.

Other possibilities are:

virus checker
bad Directshow filters
other third party software
corrupt library (check the size) -- test with a new library

An update is available at the top of this board.

[jeh14]

Will the commit charge also be astronomical until all the thumbnails are built?

I must also mention that I've been watching things fairly closely and when not (sometimes stutteringly) playing music files, MC12 was not doing anything, certainly nothing that would suggest it was busy "building thumbnails." No CPU usage, no disk IO, etc.

Is there an option somewhere to say "ignore thumbnails, don't build thumbnails for anything, pretend you never even heard of the concept of thumbnails"? If not, please make this a feature request.

> virus checker

No, this problem existed before I had a virus checker on this build.

> bad Directshow filters
> other third party software

No, this problem existed before I had installed much of anything else on the machine.

> corrupt library (check the size) -- test with a new library

As I said above, yes, but a new (empty) library is not what I want to work with. When I import all my existing MP3s the problem returns.

[JimH]

I don't know what the problem is.  I'm just trying to offer ideas for where it could be.

This thread has a problem that could be similar.  Just one of many examples.  The "weird and wonderful" thread in my signature has more.

[jeh14]

I would like this treated as a bug report. There is no way this program should ever be using a gigabyte of process-private writeable address space. EVER. 

I am a win32 and windows kernel mode developer - I know something of what I'm talking about here.

Oh, there IS an option to "build thumbnails." It's under "library & folders", "auto-import folders", "options".  I have it UNchecked, so MC should not be building any thumbnails. So that isn't it. 

I tried creating a new library and then "import from" the old one, and now everything is back to reasonable sizes! 35.6 MB working set, 21.1 MB private working set, 54.7 MB commit charge. So I have a workaround... it seems something was "funny" with the old library. But really, it shouldn't happen in the first place. Incidently, both library directories are about the same size.

[Matt]

So I have a workaround... it seems something was "funny" with the old library. But really, it shouldn't happen in the first place. Incidently, both library directories are about the same size.

Of course you're right.  It's just not a common problem.

Could you send a backup of the library that uses too much memory to matt at jriver dot com?

Thanks.

[jeh14]

Maybe. If it doesn't fit through email gateways I can set it up on an ftp server for you.

... sent. If it's not there within a few hours, post here (or email me if you can get that info from the forums) and I'll get back to you by email with ftp instructions.

[Matt]

Thanks for the library.

I can load it, but I don't get abnormal memory usage.  It peaks at around 40 MB, and uses about 3.5 MB + 34 MB virtual when minimized.

Any tips to see the spike? Thanks.

[jeh14]

Sigh... maybe it needs the whole library of MP3s. 

As I mentioned above, the library was originally produced by importing a moderately large number (a bit over 20,000) of MP3s. About half of these had originally been ripped within MC11, the other half by some version or other of MusicMatch Jukebox.