I work with the newest version. Within half an hour I have the first crash although I restartet the programm recently.
I try to send a bug report whenever I can, but most of the time it takes very long to be able to do that. So I remove all MM processes in the Task Manager. Mainly Out-of-memory crashes.

This error:
- Second crash with playing a few hunderderd songs and interface became unresponsive. Could click and browse folders, but was unable to load a playlist or play any songs. few min later:
Application thrown an exception. Not all close quary events finsihed !! (N:\Delphi\MediaMonkeyBuildTrunk\HTML5Monkey\BaseAPP. pas, line 7554). Would you like to restart mediamonkey in safe mode.
- 3th crash: Aplication thrown an exception stream write error. Would you like to restart mediamonkey in safe mode?
- 4th crash , directly at restart. Runtime error 217 at 004BFE5C

This was solved in build 2030, don't get this error anymore.

No debug flile.
New crash: Exception thrown at 0x013F4933 in MediaMonkeyEngine.exe: 0xC0000005: Access violation reading location 0x000000DE.

Mediamonkey exited without an error, however i had Visual Studio 2022 attached to the mediaMonkeyEngine.exe to monitor the memory usage.
https://imgur.com/KJqTlSL

30 years ago i used to test software on error/mistakes/memory leaks. By simply using a bankcard between a key on the keyboard.
An example, I have mediamonkey open, and clicked with my mouse on next song button. Then i walk away from my computer, and my housemate walks in, and he gives me back my book. But he misplaces it on my desk with the corner on the book directly on the > key.
So now the Next button is pressed in, until someone removes the book.
It should just skip trough all songs with ease, however...

You can simply test this for yourself while holding down the next button for a few minutes. Let it loop trough, and see what happens.

Unfortunately without debug logs this may not get fixed.

No, i stopped doing that.

However if you guys have some server space left over for some virtual machines, then i can setup some automatic basic mediamonkey testing with macro's so humans dont have to do these steps, over, over and over again. Things like that would help developers a lot, as test run in the background and generating errors by them self.
I am willing to participate in that effort, however i am unable to run & maintain it my self for 24/7/365.

Did you capture any of that in a debug logs as requested? If so, attach them to a Support Ticket.

These are the encounters sinds my last post (few hours time):
- First crash with wifi disconnect, mm could not find files, and exited without an error after about 10to20songs not found.
- Second crash with playing a few hunderderd songs and interface became unresponsive. Could click and browse folders, but was unable to load a playlist or play any songs. few min later:
Application thrown an exception. Not all close quary events finsihed !! (N:\Delphi\MediaMonkeyBuildTrunk\HTML5Monkey\BaseAPP. pas, line 7554). Would you like to restart mediamonkey in safe mode.
- 3th crash: Aplication thrown an exception stream write error. Would you like to restart mediamonkey in safe mode?
- 4th crash , directly at restart. Runtime error 217 at 004BFE5C
- 5th crash. Same as the second crash.

I stopped debugging months ago. However i kept my "automatic Virtual Machine MM debugger" at hand.
Just saw this week the new update, and saw the memory improvements, and noticed the chromium update from months ago. So i tought i go test that out now.
However wanted first to read some of the bugs, before going to test.

Never heard of Debug View crashing, MediaMonkey crashing is fine as that's what you're trying to capture in debugview.

Can you set DebugView to log to file or does it crash prior to MediaMonkey crashing?

Lowlander wrote: ↑Thu May 09, 2024 11:00 am Do you mean that DebugView crashes on you? I've never seen that happen, even when letting it capture for days.

Have happend a few times, but usually it crashed because mm froze.
And i did change the debugview keep in memory at 10k lines(other wise it captures it all by default in memory), and the rest write to file, and keep debugview minimized to make it more stable do not leave window maximized.

Agreed that memory leaks should be solved. Big part of the leaks are Within the tag-lookup. And then old items that you did stay in memory. When importing a big database for first time, you reach that memory 2gb+ within a few hours.
However i have send the full memory dumps to the dev's so they could analyze them in the past. But they where unwanted, and not looked at.

| Under normal useage, mine uses only about 200-250 mb.
Is that all 4 processes counted together, or per instance.

Hope you don't check the memory usage shown in task manager, as that shows a lower use then accutually is using, you should look at the Working Set(in Resource Manager), as that represents the usage of physical memory used.
So for me, just after startup:
MediaMonkeyEngine.exe taskmgr memory: 5,7 MB WorkingSet 26,4MB
MediaMonkeyEngine.exe taskmgr memory: 143,5 MB WorkingSet 238MB
MediaMonkeyEngine.exe taskmgr memory: 11,5 MB WorkingSet 39MB
MediaMonkey.exe taskmgr memory: 37,5 MB WorkingSet 148MB

Working set represents the usage of physical memory used. What is shown is taskmanager is virtual memory, and that is only a smaller part.
So for me after startup, 450+mb for all processes together. (but for hitting the limit you should look only look at 1 process. (because al 4 exe file can use there own set of memory))

When you do a memory dump, you can dump workingset, however you can't dump the partional virtual memory as that is incomplete.

That said, i can load a program(64bit) with 1mb memory use, shown in taskmanager, but uses 10gb in workingset, that is not shown in taskmanager under memory. So you hit the 4gb memory limit faster then, most people think.

Until windows 7 taskmanager used to show the workingset, but changed in win 8 with the improved memory optimalisations. So showing a lower memory usage, However with 32bit programming you need to think of that change, and look at working set instead to see if your getting hit by the limit.

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.

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

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.