MediaMonkey forum

Today I downloaded the newest debug version 3018, full of hopes that the big amount of crashes in the last week would end.
After 15 minutes of listening to music, MM crashes "Out of memory". I had not the opportunity to send a log, MM hangs and cound not be revived.
It is very hard to work with MM although it is a good program.

Hi,
Please make debug log https://www.mediamonkey.com/forum/viewtopic.php?t=86643 then ZIP it and attach to support ticket.

In our tests MM 3018 RAM footprint is 30% lower than in 3005 due the number of MEM leaks fixes.

I would like to make a debug log, but MM hangs and freezes, so I cannot reach the point where I can make a debug log. Sorry

How much free memory does your system have? A screenshot of your task manager might be useful...

After the first crash, did you do a full restart of Windows to clear out any residual bits?

I would try to run MM again after such a restart, and without running anything else, and see what happens.

The 'Out of memory' crash is not the only type of crash which happens. Other crashes did not tell the reason. Sometimes I can send a log sometimes not.
After the crashes I remove all the MM processes from memory to be able to restart MM.
I think, the reason for all the crashes may originate in the huge database I have. In my database there are near 12000 albums.

Does 12,000 albums mean something like 120,000 tracks?? Wow!! I have only 14k tracks.

If you can get MM running long enough, I would attempt to make a backup of your database using the menus - file, manage database. If that does not work, you could find the file "MM5.db" in your appdata/roaming /mediamonkey 5 folder, and copy it somplace safe. By the way, how big is that file???

Then try doing a full database maintanance under that same menu. It is possible that it has become corrupted, and this is causing the crashes.

Actually Debug View captures all this. It doesn't matter if MediaMonkey keeps, working, freezes or crashes, it's all captured in Debug View and can be used by the developers to determine why this happens on your setup. This is better than the logs send from within MediaMonkey in many cases as it captures a longer history.

If Windows itself also crashes, just set Debug View to log to file and you can provide the saved file after Windows reboot.

Yes, I have 282394 files in the database.
I reconstructed the database, the long way. Before that, the database had 947 MB, after that 952 MB.
Will see if there is a better behavior of the program.

Lowlander wrote: ↑Sun Apr 28, 2024 12:13 pm Actually Debug View captures all this. It doesn't matter if MediaMonkey keeps, working, freezes or crashes, it's all captured in Debug View and can be used by the developers to determine why this happens on your setup.

If Windows itself also crashes, just set Debug View to log to file and you can provide the saved file after Windows reboot.

The problem with capturing debug logs is that when MMW5 running debug eventually freezes (and it will), the response from tech is that the reason for the freeze is due to debug logging. This makes capturing debug logs futile.

That may have happened in specific scenario, but is generally not the case. I've not run into this scenario. Please do capture the debug log of MediaMonkey freezing and submit it to support.

I have tried sending debug logs to be told that my logs are too big and the freeze happens due to debugging. I was specifically told to stop debugging

The problem is for these sporadic crashes we may have to run the application for a very long time. Hours of run time will cause a freeze during debug logging. However, the same freeze happens even with the non-debug version. I wonder if you guys still have debug code in the release version that may be triggering the same freeze.

Had/have the same struggle to capture the error after a few days of non stop mediamonkey running. Debugger usually bugs-out.

For me media monkey always crashes when memory goes over 2gb, crashes happen then between 2.4 and 3.8 gb of memory use, when using i for a few days. My understanding is that 32bit applications, the max the application can access is 2gb for a single 32bit application. With LargeAdress enabled in the code it can go up to 4gb, but rarely can use up to 4gb. Duo to some overhad.
Can you guys provide a 64bit version, so we can test out if we can keep it open for longer dan 2 or 3 days and not get limited by the 32bit limitations

Much better would be to fix the memory useage (leaks) problem.

I think there should never be any need for this program to use that much RAM.

A 64bit version would just postpone the effect, and would run most inefficiently.

Under normal useage, mine uses only about 200-250 mb.

Do you mean that DebugView crashes on you? I've never seen that happen, even when letting it capture for days.

Using MM for days without restarting it, means, that unused memory is not freed. Maybe there is a source of errors. A hint in this direction is the fact, that the gaps between consequent tracks become larger the longer MM is running.