View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020834 | MMW 5 | Tagging / organizing (properties / auto-tools) | public | 2024-04-09 21:06 | 2024-05-20 07:56 |
Reporter | lowlander | Assigned To | |||
Priority | immediate | Severity | major | Reproducibility | sometimes |
Status | resolved | Resolution | fixed | ||
Product Version | 5.0.5 | ||||
Target Version | 5.0.5 | ||||
Summary | 0020834: Album Art Lookup Memory Leak | ||||
Description | There are times where MediaMonkey slows to a crawl (menus can take 10-30+ seconds to show). Memory usage by MediaMonkey is over 2GB and debug log shows lots of Requesting URL https:// ***.mm.bing.net/******** This issue is reproducible with some regularity. | ||||
Steps To Reproduce | Prior to this I was tagging Artwork to a few MP4 files, by manually adding Artwork (which has to happen through Image lookup. This eventually let to a white screen in MMW (first log only). 1 Select MP4 file (music video) 2 Properties > Artwork 3 Lookup image 4 Browse 5 Paste image URL 6 Repeat step 1 through 5, after a while MM starts increasing mem usage and log shows loads of bing connections. --> Note, in most instances no Artwork lookup results are shown as Browse is imitated immediately on window load --> Note, files are MP4 files, lookup happens per file, files have no metadata | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Fixed in build | |||||
|
This looks like a memory leak--each image lookup operation increases memory utilization by about 20MB. EDIT: You can ignore most of this comment and just skip to Method 4 since it gets to the root of the problem. Method 1: Martin is able to replicate as follows: 1 Select MP4 2 Tap Properties > Artwork > Lookup image > Browse 3 Enter an URL that points to an image into the filename field Repeat this for several files in a row --> at some point MediaMonkey starts feeling slow / mem usage is elevated / log shows lots of bing connections (despite no lookups happening at that precise moment) and eventually white screens. I'm able to replicate this in a number of other ways as well with audio files: Method 2: 1 Select track 2 Tap Properties > Artwork > Lookup image 3 Select an image and save it to the tracks tag --> Memory utilization increases by 20 MB each time this is done! Method 3a: 1 Add 30 tracks that are missing artwork to the Playing queue 2 Set the Preview window to show the currently playing track 3 Play the tracks 4 In the Preview window tap Artwork: Lookup and save one of the images --> Memory utilization grows by 20MB for each track! Method 3b: 1 Add 30 tracks that are missing artwork to the Playing queue 2 Enable album lookup 3 Set the Preview window to show the currently playing track 4 Play the tracks --> Artwork is automatically looked up for the playing track and memory utilization grows by 20MB per track! Method 4: 1 With album lookup disabled, set the Preview window to show the currently playing track 2 Click Artwork: Lookup and then press Cancel. Keep repeating step 2. --> Each time artwork is looked up, memory utilization grows by 20MB! On my machine, memory utilization for MMW 2024 grew from ~280MB to 1GB after a few minutes of looking up images. |
|
Tested 3017 and the original issue seems to be much improved. However, there are still cases in which AA causes massive increase in memory usage: a) Switch to Music > Albums [Grid view] (Lookup disabled), and scroll down and back up through several hundred albums. The more one scroll --> the more memory usage continues to increase (from a base of 250MB to double that, very quickly). b) Do the same as the above in Music > Artists [Grid view] --> Same result c) Do the same in Music > All tracks [List view] --> memory utilization caps at around 300MB 2 Enable the Artwork column and then scroll up and down --> memory utilization continues to increase! So it seems that whenever video thumbnails are scrolled, memory utilization increases to an unexpected degree. |
|
All of these points are not related to artwork lookup but how chromium working and frees memory and i'm not sure we can do anything with that. |
|
Setting as Resolved, since according to my testing there isn't anything abnormal atm. Rusty, please reopen in case you still find anything wrong. (Note that this isn't completely deterministic due to the nature of GC in Chromium. And that some significant memory utilization is expected where there's a lot of images. That said, there shouldn't be a constant growth and generally speaking, memory utilization should remain stable.) |