View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017547 | MMW 5 | Playback | public | 2021-02-14 00:46 | 2021-05-03 13:35 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | random |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0.1 | Fixed in Version | 5.0 | ||
| Summary | 0017547: Playing mm for hours (--> crash 875B000 : fixed) --> increased memory utilization | ||||
| Description | MediaMonkey was running for about 25 hours, but not doing anything. On close, it 'black-screened' with the following crashlog: 875B000 | ||||
| Additional Information | CPU/Memory utilization issues reported at https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=98780 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2334 | ||||
| related to | 0017655 | resolved | Ludek | Crash on close after running for awhile (crashlog ID 8F658A3F ) |
| related to | 0014592 | closed | petr | Upgrade to the latest Chromium |
| related to | 0017755 | closed | Ludek | Memory leak while casting to DLNA client |
| related to | 0017772 | closed | Ludek | Significant memory leak while browsing content |
|
|
Fixed in 2311 |
|
|
Verified 2211 MM5 was started for 34h and closed with no issues, TEST Note: I've done few Deep sleep functions that my MB support and it also came back fully working. Also tested WOL function to restore PC from Deep sleep after MMA sync initiates (No timeout) System woke within 3 seconds and sync started. |
|
|
This occurred again for me with 2313 (though no crashlog resulted). Retesting. |
|
|
Unable to replicate with 2315. |
|
|
I also haven't experienced such crashes since 2315 |
|
|
A variant of this just occurred for me with build 2316. Run MM and play music. Then stop playback. Leave MM5 running and leave PC for 25 hours (pc isn't set to go to sleep--just to require sign-in) --> On sign-in, MM is frozen! Note: - MM is frozen on Music > Genres > Acoustic Rock > [List] - NP list is loaded with 1107 files [List] - Memory utilization seems normal I'll try to replicate with dbgview running. |
|
|
I tested this again as follows: 1 Run MM 2 Initiate playback of 400 tracks 3 check status 26hrs later --> UI responds normally but 1.3GB memory utilization! Perhaps this could be an artifact of dbgview running, BUT the debug log is only 25MB so I suspect there is a memory leak. Debug log saved to ftp--hopefully it contains some useful info. |
|
|
From the debug log I can cofirm that it started on values like: (R) MemRAM: 234.8 Mb, MemPrivate: 214.5 Mb, MemVirtual: 608.2 Mb and ended up with: (R) MemRAM: 739.3 Mb, MemPrivate: 719.4 Mb, MemVirtual: 1.1 Gb after 25 hours of playback. The memory utilization grown slowly with files being played and in half of the process the utilization was: MemRAM: 536.7 Mb, MemPrivate: 507.0 Mb, MemVirtual: 946.7 Mb It seems that with every lyrics lookup it jumped up a bit, but there could be a leak also in playback itself, almost all tracks have been played via in_mfaudio.dll plugin and not all have been searched for lyrics (while the memory utilization was still growing) So we need to ensure that there isn't a leak either in (or both): 1) in_mfaudio.dll plugin 2) Lyrics lookup 3) Note that there were also several YouTube tracks played, but only the first one bumped memory up +50 MB, so I suppose it was because of caching YouTube playback window/process ? |
|
|
1) I analyzed all allocations and releases and everything is in pairs and called during playback as it should, could not find any leak. 2) lyrics lookup remembers results from the last hour, if not saved to tag, but it should not be such problem 3) yes, it is caused by Google player, we could not affect this. Please try to compare the results of longer playback of the same files when DbgView is closed and when is opened. I think it should be noticeable after 1-2 hours, whether it makes difference. |
|
|
The crash on close related to UPnP is already fixed as 0017655 As for the leaking, it might be the player visualizer leaking the memory, namely this closure when comparing the snapshots: https://www.dropbox.com/s/o9oade3uqtyzk3j/screenshot%202021-03-17%2013.33.38.png?dl=0 when double-clicking the closure then we can see that it is setTimeout in the queueRequest (mminit.js): https://www.dropbox.com/s/qtydnsbrj1dfp9v/screenshot%202021-03-17%2013.35.51.png?dl=0 Michal, please verify. |
|
|
This was not leak, only garbage collector did not release everything yet. There does not seem to be any leak during playback in JS part of application. |
|
|
Another test. Left 2325 debug playing 17hrs with Preview and Player disabled (Main Panel:Home, Playing were all that was enabled). --> Utilization grew from ~287MB --> ~437MB MM Closed normally. |
|
|
Michal indicated that MEMCHECKing does not show any leak in Delphi part, DevTools does not show any leak in Javascript part. This leaves chromium as the likely source, and as such it would need to be re-evaluated with an updated version of chromium. |
|
|
Analyzing the log again I think that the reason for the memory leak could be the same as in 0017755 i.e. lekaing prepared queries. Please re-test in 2334 |
|
|
Tested 2334 and this seems to be improved though there's still room for more improvement: after running MM5 and playing for 8 hours overnight, memory utilization grew from 240MB to 345MB. Note: Local playback seems to leak more memory than DLNA ( 0017755 ) |
|
|
Strange, I don't see any leak when using local playback. Tested 4 hours of playback, it started at 187 MB and sometimes it was above 220 MB, but after the 4 hours it was lowered to 184 MB (tracks still playing). So I don't think there is a leak related to playback. Not sure what could be the difference, I tested with WASAPI ouput and lyrics auto-lookup disabled, main window was minimized. For build 5.0.1.2400 added a debug output of allocated internal objects (created in delphi) that will be visible in debug log every minute (just like currently the utilized memory is seen in the debug log every minute). EDIT: After 8 hours of playback it is 195 MB, so I definetely do not observe the leak in my environment. |
|
|
I don't think there is a leak while playing, but I found a _significant_ leak while browsing content -- fixed as 0017772 |
|
|
Verified 2238 After 8h and scanning/refreshing UI and AA utilization was stable on 280MB from 230MB on start of MM. TEST NOTE: UI was more responsive in 2338 than in 2336 about 30% (50-100ms) Faster on view refreshing and caching AA. |
