Still waiting on further information from developers.

[quote="nohitter151"]I'm sorry, I linked to the wrong tool. [/quote] :roll:


[quote="nohitter151"]Use "CFF Explorer.exe" from http://www.ntcore.com/exsuite.php to edit the
'File Header' and DISABLE the checkbox "App can handle > 2GB address space" for
MediaMonkey.exe and MediaMonkey (non-skinned).exe .
See description at: http://www.ls-uk.info/forum/index.php?topic=54930.0[/quote]


[list=1]
[*]Installed 4.0.6-debug over 4.0.3.
[*]Executed 4.0.6-debug -- [url=http://chromejob.com/mediamonkey/20120721a_mm406_before_cffexp.png]confirmed previous CPU overutilization.[/url]
[*]Edited file header for both executables as described above.
[*]Ran the non-skinned EXE again, ... [url=http://chromejob.com/mediamonkey/20120721b_mm406_after_cffexp.png]same issues.[/url] [/list]

For fun and giggles, I tried the following to eliminate any extensions that I have installed:
[list=1]
[*]Reinstalled 4.0.3.
[*]Remove all [url=http://chromejob.com/mediamonkey/20120721c_extensions.png]add-ons and extensions.[/url]
[*]Installed 4.0.6-debug.
[*]Ran 4.0.6 again ... [url=http://chromejob.com/mediamonkey/20120721a_mm406_before_cffexp.png]same CPU utilization[/url].[/list]

Probably unrelated (since 4.0.6 doesn't have an issue about it). The MM.DB file has swelled to 58 MB (stored on a local hard drive)! I don't recall it being nearly that huge under 3.x. Yes, I have run File | Maintain | full optimization. :wink:

I'm sorry, I linked to the wrong tool.

You need to try the following from the KB:

Use "CFF Explorer.exe" from http://www.ntcore.com/exsuite.php to edit the
'File Header' and DISABLE the checkbox "App can handle > 2GB address space" for
MediaMonkey.exe and MediaMonkey (non-skinned).exe .
See description at: http://www.ls-uk.info/forum/index.php?topic=54930.0

[quote="nohitter151"]I wonder if it has something to do with the change so there is no longer a limit to how much memory MM can use. Details at:
http://www.ventismedia.com/mantis/view.php?id=9326

To confirm you could use this tool:
http://www.ntcore.com/4gb_patch.php

so that the current MM version is limited again to only 2GB of RAM.[/quote]
[b]No change.[/b] This system isn't 64 bit. You can find the specs on thinkwiki.org.

I'll post a log when the current Manage Library | Optimize Database (Quick) is done. Under 4.0.3, took about 15 seconds. It's been churning for 5 minutes so far under 4.0.6.

... Never mind, I'm cutting the log off. http://chromejob.com/mediamonkey/20120716_mm4.0.6_after_ntcore_4gbpatch.zip

I wonder if it has something to do with the change so there is no longer a limit to how much memory MM can use. Details at:
http://www.ventismedia.com/mantis/view.php?id=9326

To confirm you could use this tool:
http://www.ntcore.com/4gb_patch.php

so that the current MM version is limited again to only 2GB of RAM.

Same thing this morning as always with 4.0.6.1501, started up, maxed out CPU, was unresponsive while I attempted to change views in the tree, then finally generated a problem report which was sent (did so previously, but failed to send, I thought it was another problem with 4.0.6).

Reverted back to 4.0.3.1476, started it up (no reboots or anything, just made sure 4.0.6 wasn't still running in memory), [b]and no such CPU maelstrom[/b]. As far as I can tell, it successfully downloaded 5-6 podcasts within 5 minutes. I'll be staying with 4.0.3 until you guys fix this.

I'm pretty angry with you guys. I didn't buy a lifetime license to become a Beta tester for you, I have enough software to QA in my day job. :roll:

Currently, there's about 64KB in w:\mp3\src. There's about 3.19GB in w:\mp3\podcasts\ (stored locally due to significant churn), only This American Life podcasts are moved by AutoOrganize to \\192.168.1.11\share$\mp3\thisamericanlife\ . The only other file monitor is for \\192.168.1.11\share$\mp3\src\ which has the bulk of my library ... but this CPU utilization was not indicated in 4.0.3; it worked just fine. This problem is brand new for 4.0.6.

No devices were accessing or streaming via DLNA during these tests. (I presume the logs would indicate that.)

What do you have in W:\mp3\src\ and how many File monitors you have activated? Also any DLNA devices access MM and/or play tracks in MM so that Re encoding could happen.

Log files do not show any abnormalities or hogs in MM UI just normal behaviors?

Environment: Win XP Pro SP3, bulk of music library on NAS share, podcasts locally stored, temporary music library locally stored.
MM version 4.0.6.1501

Immediately upon updating to 4.0.6, I noticed MM running very very slowly. Systinternals Process Explorer indicates its maxing out the CPU at or above 93%.

I've run the debug version, and recorded three files. With DLNA sharing enabled, MM 4.0.6 seems unable to close the process entirely, and has to be killed. The final log (without kernel tracking) includes MM 4.0.6 being run, closed, then run again (the prior process had to be killed, then DLNA being deselected, and closing (process closed itself normally.

I've left MM 4.0.6 alone for 5-10 minutes at a time at runtime, and the CPU behavior doesn't seem to abate for at least 10-15 mins or longer, just keeps chugging away (as illustrated):

http://chromejob.com/mediamonkey/20120708c_mediamonkey_cpu_hog.png

Net result of this is that nothing else can be performed on the computer while this is occurring.

Log files attached to the support ticket, and available here: chromejob.com/mediamonkey/20120708_gqn-249754_mediamonkey_dbug_logs.zip