View Issue Details

IDProjectCategoryView StatusLast Update
0009326MediaMonkey (current)Otherpublic2012-07-12 14:20
Status closedResolutionfixed 
Product Version4.0.5 
Target Version4.0.6Fixed in Version4.0.5 
Summary0009326: MM Observes x86 2GB RAM usage limit
DescriptionOn Large MM databases with 400k+ tracks using heavy multi threading features like thumb creating, album art view, mass tagging, can introduce x86 2GB RAM limitation where x86 app is limited to use only 2GB of RAM where other 2GB are reserved for System. This is more viewable on x64 system where users have 6GB+ of RAM and and allowing application to allocate rest of allocatable 4GB is not an speed issue as System have more than enough RAM to allocate before it needs to SWAP.

Using Simple 4GB patch Application from fixes MM exe and MM do not crash anymore.
Additional InformationTicket:
TagsNo tags attached.
Fixed in build1489


related to 0009421 resolvedLudek Ripping fails for some users when 'Secure read' mode is selected (regression on x64) 



2012-05-09 08:51

administrator   ~0031069

To be added to our build batches.


2012-05-09 18:22

developer   ~0031080

Fixed in 1489


2012-05-14 03:12

developer   ~0031117

Fix confirmed by user and me using 1489 and I was able to make MM use ~3471MB of RAM


2012-06-11 19:02

developer   ~0031349

Last edited: 2012-06-11 19:03

View 3 revisions

This issue causes some regressions related to ripping 0009421 for users on x64 platforms.

More info here:

So I guess that we should revert this in 4.0.6 as it causes such a unpredictable regressions.


2012-06-11 21:03

developer   ~0031350

The really strange thing is that it occurs only with Secure mode. Because secure mode is completelly our code that calls the same Primo's functions like standard mode. Based on the log it fails in the Primo's function.

Can someone with 64bit operating system try to test this and confirm that it really happens only with secure mode?


2012-06-12 14:10

developer   ~0031352

I am on Win 7 64 bit and I just ripped a CD in secure mode without any problem. Build 1495


2012-06-12 16:35

developer   ~0031354

Peke, Stephen and Rusty confirmed no problems when ripping in secure mode.

We confirmed with the user here:
that the problem doesn't appear for him when size of read buffer is the same as in case of standerd read (63 KB) then it works fine, but if it is 512 KB or bigger (like in case of secure read) then it fails. So the solution is reduce size of read buffers in case of secure reading. Tracking in issue 0009421

This one can be resolved/closed.


2012-07-12 14:20

administrator   ~0031556

In build 1601 I updated the build steps so that the external tool is no longer necessary, we set the necessary flag directly during compilation.