Memory Leak, particularly when tagging [#16655]

[1337haXXor]

Well I've found the source of likely most of my crashes. I happened to have task manager up and noticed that every time I edit a track's tag, the memory usage goes up by .5 to 2MB, per track, per edit. My most recent crash showed my memory at just over 2000MB. It typically starts around 320MB. In addition, the memory seems to just increase by itself very slowly, though I haven't noticed if this caps at any point. I started MM once, played a few seconds of a song and paused, and looked back about 30 minutes later and the memory had gone from 320MB to about 440MB.

For reference, I have a large library, mostly FLAC. More than 50,000 songs. Currently on a mostly full, old, 5400RPM drive, which I suspect is the cause of many of my other problems and slowdowns, but I'll be getting a shiny new SSD on Black Friday, so hopefully that fixes some.

Auto-Organizing via Ctrl+R adds a good chunk of Memory usage as well.

EDIT: Also, all tagging is occurring while music is playing. Thought I should add that.

PS. Thanks for fixing the adding duplicates and non-duplicates to playlists and returning the dialogue box for moving other files (artwork, logs)!

[Ludek]

Hi, I cannot replicate the leaks when tagging, but from your crash log(s) I see that you are using an outdated build (5.0.0.2201) -- more than two months old.
Please upgrade to the newest beta (currently 5.0.0.2209) and let us know whether you are still seeing the issues?

[1337haXXor]

I realized that a bit ago, and upgraded to 2209 last night.

Had the same bug occur just this morning. Since starting up MM, I added 6 albums. Tagged the first few and played without issues. Somewhere during tagging the 4th or 5th, which all had different artists (arrangement album), my RAM usage hit about 900MB and the program crashed again.

I'm running Windows 10, LTSC, I'm not sure what other information would be pertinent.

EDIT: My tagging also includes volume leveling per track and album.

[Ludek]

Somewhere during tagging the 4th or 5th, which all had different artists (arrangement album), my RAM usage hit about 900MB and the program crashed again.

Could you please test tagging the files one by one and see on which file it hits the 900MB usage and share the file(s) that blows the RAM with us to analyze?
You can upload them to a free file hosting service (DropBox, Box, MediaFire, ....) and send me private message with the link.
Thanks!

[MiPi]

I could not reproduce too. Could you find exact steps how to achieve growing of RAM usage with several files and send us these files? So we could try exactly the same steps with the same files, it could be something specific for your usecase and files.

[Peke]

Hi,
I can't reproduce it also, even used on large number of Video Files.

[1337haXXor]

Sorry for the delayed response! Umm, it's not specific files, it's just anything I tag, edit, or add to the library. Everything adds a tiny amount of RAM usage and it doesn't appear to decrease. I'm not using any particular addons or anything.

Let me test right now.

Program's been running for a couple hours, I've listened to about 2 albums, one on the internal player, one casting to a Chromecast. RAM usage is currently at ~460MB.

Okay, I actually went to do an errand, it's been about 10 minutes, RAM usage is just over 470MB.

I've added Bryan Adams' first album, in FLAC. MM auto-volume-leveled it. After that, I updated the tags (genre, release date) and Auto-Organized it (Ctrl+R). It's sitting at ~490MB.

I did the same thing with his second album (also fixed the album name), and I'm at about 530MB.

For me it's been directly related to the amount of tracks added. Both these albums are less than 20 tracks total, but I've added game soundtracks which are over 100 tracks, so it doesn't take many of those to crash it.

EDIT: I know I have the other bug thread up; I suspect a lot of these are connected. I get quite a lot of "blanking," which sometimes I can just click on a playlist and back to "All Tracks" and everything's fine, but sometimes that's the precursor to a crash. As Ludek stated on the other thread, there's something about updating being slow, I wonder if it's all related to that. It's a relatively old, 5400RPM 2TB laptop drive that has about 1TB of music, and is almost filled with other media otherwise. Could the slowness to update be related to the drive, and could that be causing slowdowns/crashes?

EDIT2: About an hour later, the usage has returned to about 470MB, which is pretty decent. I'm starting to think the combination of the specific build and the hard drive were exacerbating the issues.

[Peke]

Hi,
Have you tried to play with Performance options?

[1337haXXor]

Hmm, I must've at some point. Not sure what the default cores is set to, but all of mine are set to half (6). And the Priority is set to the highest, Normal. Apparently the default is Lower. Should I set it to all cores?

Generally the tagging, leveling, etc., are VERY snappy, going through 100+ songs in just a few seconds.

[Barry4679]

Not sure what the default cores is set to, but all of mine are set to half (6). And the Priority is set to the highest, Normal.

My PC is at default. All cores at 4, and Priority at lower.

[1337haXXor]

Okay, I've dropped down the priority to Lower and the cores to 4.

But I have new, fun info. This most recent crash, I found out an even simpler way to ramp up the RAM usage; just looking at a file's properties! I literally hit Shift+Enter to view a file's properties, then hit "Next" at the bottom. Then just keep hitting it! I watched as viewing each file increased my RAM usage by between .2MB and 2MB on average, with a few jumping it up about 6MB. My RAM went from ~400MB to I think around 650MB comically fast, before predictably crashing.

Not sure if it makes a difference, but all of these issues relate to the MediaMonkeyEngine process. The regular MediaMonkey one stays around a cool 100MB, just playing the song.

[Ludek]

I literally hit Shift+Enter to view a file's properties, then hit "Next" at the bottom. Then just keep hitting it! I watched as viewing each file increased my RAM usage by between .2MB and 2MB on average, with a few jumping it up about 6MB. My RAM went from ~400MB to I think around 650MB comically fast, before predictably crashing.

I cannot replicate, for me the RAM usage grows from say 200 MB to 230 MB after 100 fast clicks on the [NEXT] button, but then stays at 230 MB for all the other clicks and the "X files to be tagged" stays at 25 or so.
Could you please generate debug log (item 4b here: https://www.mediamonkey.com/forum/viewt ... 30&t=86643 ) and send me private message with the link?

The other issue is that [NEXT] starts updating of the file tag even when actually nothing was changed in the Properties!! This will be fixed as https://www.ventismedia.com/mantis/view.php?id=16109

[1337haXXor]

Messaged you.

[MiPi]

Thanks. We have found possible problem, that was causing the crash probably, should be fixed in the next release.

[1337haXXor]

I reported this problem a while ago, and while I'm happy to report that MM hasn't outright crashed like it used to in a while, it's still increasing memory/CPU usage until it slows my whole computer down. This is solved with exiting and restarting the program, and doesn't SEEM to increase with simply listening to music (only updating the last played and playcount node in the database, I guess?). But if I add a few albums to the library, edit a few tags, do a bit of file moving (I have my music to be sorted in a separate location, add it to MM, edit tags, then auto-organize). All of these have lots of DB edits, and I assume it's what bogs down the system.

I've taken two debug logs. These are after 6 or 7 album addition with all my aforementioned edits/tagging. The first log is when the most recent album was still in the old, un-auto-organized location (an older, slower HDD). The second is after I auto-organized to my main drive (fast SSD). The logs simply show a track finishing, and the next one starting. My RAM usage at this time was sitting at over 1GB, and my CPU during track changing hit 100% for about 3-5+ seconds, sometimes locking my computer during that time.

In addition, this would bring about the other typical(?) glitches, such as forced refreshes, oftentimes which are improper. They display the wrong amount of songs (sometimes an "earlier" number of tracks, like how many I had when I first opened MM in the morning, before adding tracks), visual glitches of reverting tags (showing an album with the old artist name, for example, before I edited that tag), and I recall you guys reporting a fix of no longer showing 2000 or 4000 on refreshes or something? Which is the case, but it seems like the number was just bumped up to 32000, because my library will freeze at that amount often as well. ALL of these visual bugs are fixed 95% of the time by changing to another view (a playlist, device menu, etc.) and then back again. The other 5% of the time I have to do it twice. I don't mean to double stack issues, I can make a separate post if needed. I've had all of these issues before constantly, but they happen increasingly as the program "bogs down" over time.

I'm currently on 2247, but these issues have been persistent pretty much always. Again, the full-on crashes seem to be resolved, but not the general slowing. I generally am on the newest version, though sometimes (such as now) I can get 1 or 2 behind. System is very powerful, and shouldn't be the issue (i7-8700, 16GB RAM).

Log 1 - http://www.mediafire.com/file/edn3z0aa3 ... S.LOG/file

Log 2 - http://www.mediafire.com/file/f05p9tp8z ... 2.LOG/file