View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0009326||MediaMonkey (current)||Other||public||2012-05-07 22:49||2012-07-12 14:20|
|Target Version||4.0.6||Fixed in Version||4.0.5|
|Summary||0009326: MM Observes x86 2GB RAM usage limit|
|Description||On 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 http://www.ntcore.com/4gb_patch.php fixes MM exe and MM do not crash anymore.
|Tags||No tags attached.|
|Fixed in build||1489|
||To be added to our build batches.|
||Fixed in 1489|
||Fix confirmed by user and me using 1489 and I was able to make MM use ~3471MB of RAM|
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.
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?
|I am on Win 7 64 bit and I just ripped a CD in secure mode without any problem. Build 1495|
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.
||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.|