View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015258 | MMW 5 | Main Panel | public | 2018-12-13 03:46 | 2018-12-17 04:28 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015258: CPU Utilization sometimes stays at 50% on certain nodes | ||||
| Description | In build 2139 the normal startup process is that MediaMonkeyEngine.exe is at 50+% for about 10s and assuming MM is in the Music node it then goes to 2-3% after that process is completed. If the user then navigates to Music > Location > D: > My Documents > Temp > DL > 226 50s & 60s Oldies (USA) (192kbps), CPU utilization briefly goes up and then back down to 2-30%. BUT, on occasion, if the user instead starts up in Music > Location > D: > My Documents > Temp > DL > 226 50s & 60s Oldies (USA) (192kbps), then CPU utilization of MediaMonkeyEngine.exe is at 50+% on startup, and remains at 50+% even after the hourglass goes away! Switching to > Music causes CPU to go to 2-3%, but switching back to the problematic path --> utilization jumps back to 50+% and stays there!! In this state, use of functions such as Auto-tag don't seem to work (lookup shows a white screen). The problem is triggered as follows: 1 Switch to Music > Location > D: > My Documents > Temp > DL > 226 50s & 60s Oldies (USA) (192kbps) 2 Select 20 different non-consecutive tracks (I'm not sure if this is the trigger, it worked a couple of times but I suspect that it's actually something else since it's not consistent). 3 Restart MM --> The view opens, but briefly (for about 3 seconds) displays a very large hourglass on the left hand side, covering about 6 tracks, as if it was preparing a browser view (even though MM is in a list view). This is critical--the bug only occurs when this large hourglass appears. --> Hourglass appears in the upper-right corner in relation to artwork processing for inaccessible tracks. MediaMonkeyEngine CPU @ 50%. --> Line 2580: CPU utilization then stays at 50% even though this process is over. --> Line 2606: Switch to Music node. CPU utilization goes to 2% --> Line 2829: Switch back to the location node. CPU utilization goes to 50% and stays there Note: I've seen this problem in 2138 as well, but it's possible that it's existed for awhile. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2140 | ||||
|
|
Additional info: 1) if I navigate up a directory and then back down, the bug doesn't reccur. i.e. Startup in problem directory Switch 'up' one directory Go back 'down' to the original directory --> bug doesn't occur (this is in contrast to switching between the Music node and the original directory where the bug does recur) 2) Enabling/disabling recursive browsing has no effect 3) I can't seem to replicate the problem if Subview > Folders is disabled |
|
|
To clarify, it is combination of several bugs: a) there is a bad count of subfolders for this particular folder in Rusty's database, it should be zero and in that case MM wouldn't attempt to read the subfolders at all b) loading of the subfolders from DB takes more than 500 ms for some reason (should be instaneous) and thus the progress animation (in folders sub-view) is shown c) because the loading progress div is cached and isn't subsequently used for the first subfolder (because of issue a) above then the progress animation consumes CPU time even if it is hidden d) the animation is unnecessarily CPU intensive -- tracked as 0015267 |
|
|
Fixed |
|
|
The problem of permanent 50% CPU utilization in the affected node is resolved in 2140, however, issue a)/b) remains, though Petr already has a fix. Noting this as a test reminder re 2141. |
|
|
Verified 2141. |
