View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015735 | MMW 5 | Tagging / organizing (properties / auto-tools) | public | 2019-06-11 21:19 | 2020-07-22 21:01 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015735: Crash on Mass Edit of Track Properties (build 2181) | ||||
| Description | 1 Select 100 tracks 2 Empty and check all fields except Title and Artist 3 Click OK to accept the changes and initiate tagging --> MM crashes (white screen) Debug log: 249A1482 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2182 | ||||
|
|
Based on the crash log there was "Out of memory" exception. MediaMonkeyEngine.exe utilized more than 1.6 GB of memory and there were 24 of "TSharedUIList<T>.processTableUpdate" tasks in the task queue. i.e. It seems that shared lists (or rather whole tracklists) are leaking ... EDIT: Added more debug info to 2182 + fixed some code tweaks related to this issue So please re-test in 2182 |
|
|
Re-opened, there are still some leaking lists (based on the new debug info)... |
|
|
I've replicated the problem again with another crashlog (249AAE9E) in 2181. I've been doing a lot of tests that involve tagging and it's generally stable. The only thing that I can think is common to the instances in which this crash occurs is that in both cases there were extended tags that were deleted. i.e. in Properties > Custom, select and delete extended tags and apply to all (in addition to all the other tags that were selected/deleted). Test note: replicable with 'Now that's what I call music! 99' album. |
|
|
ok, I am solving the lists leaking issues now, but it is true that the list leak isn't so huge. So in your case I suspect that it leaks on a particular files when tagging the extended tags. This time the MediaMonkeyEngine.exe utilized 1.7 GB of memory (based on 249AAE9E) when it crashed with the "out of memory" exception. Could you please upload the 'Now that's what I call music! 99' album on FTP? |
|
|
I shared the album with you. Note, though: all tracks on that album are MP3s. |
|
|
I am trying with the 'Now that's what I call music! 99' album and I cannot replicate the issue These are the steps that I am using: 1) Scanned the album into library 2) Selected all 39 files > right-click > Properties > Custom tab 3) Removed extended tag "Upload: Hunter" 4) Clicked OK => 39 files tagged with no crash and no memory jump up (MME.exe utilizes still about 220 MB) Could you describe your steps that leads to the 1.7 GB of memory utilization for the MME.exe process? And if you can still replicate then please generate also the standard debug log (using DbgView) so that I can see all the history leading up to the "out of memory" issue. |
|
|
I'll resend the files in their original state in which I received them. Here's exactly how I replicated the problem. https://www.youtube.com/watch?v=k25XT3huD18 Debug log and crashlog for this are on the ftp server. |
|
|
You haven't re-sent the files so I still cannot replicate, but based on the logs the "Out of memory" always appear when removing cached thumb path from thumb cache. It is a new code added by Petr in course of 0015689 (it is new in build 2179) I am reviewing the code and will add more debug messages (in case I fail to find the code glitch) EDIT: it seems that the key factors to replicate are: - enabled the artwork column in the file listing (to see many same artworks for the individual tracks) - remove the covers when mass editing I am finally seeing where the problem lies and preparing the fix (was regression in 2179 by 0015689)... |
|
|
Fixed in 2182 |
|
|
Verified 2183 Regression tested as like Ludek I can't replicate |
|
|
Unable to replicate in 2261 Closing. |
