View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014596 | MMW v4 | Other | public | 2017-12-21 20:02 | 2018-01-23 11:18 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1.18 | ||||
| Target Version | 4.1.20 | Fixed in Version | 4.1.20 | ||
| Summary | 0014596: High CPU utilization during playback (regression) | ||||
| Description | I just noticed that CPU utilization is much higher during playback, starting with MMW 4.1.18. 4.1.17 (tested portable) ------ M4A (Ahead by a Century): 5-9% MP3 (Ghosts of Beverly Drive): 5-7% Flac: (5 days in May): 5-8% OGG: (Are you gonna go my way): 5-8% 4.1.18+ (tested portable and normal install) ------ M4A (Ahead by a Century): 5-11% MP3 (Ghosts of Beverly Drive): 7-45% Flac: (5 days in May): 5-8% OGG: (Are you gonna go my way): 5-11% Notes: - although the biggest difference appears to be with MP3 files, there was also a slight difference with M4A files. - the difference isn't just a change in average CPU but rather the characteristic sawtooth pattern of CPU utilization in 4.1.18+ (most noticable with the MP3 file). - in some cases, once the bug occurs, MMW becomes very sluggish and even restarting MMW (or even an earlier version of MMW that doesn't experience the bug) doesn't solve the sluggishness--only a system restart solves this. - audio dlls in build 4.1.20 are different than in all previous builds: id3lib.dll: 4.1.17/4.1.19 - 501464 B ; 4.1.18 - 620,760 B ; 4.1.20 - 501440 B in_wmp3: 4.1.17/4.1.19 - 484056 B ; 4.1.18 - 114392 B ; 4.1.20 - 484032 B in_mfaudio.dll: 4.1.17/4.1.19 - 572632 B ; 4.1.18 - 108248 B ; 4.1.20 - 572608 B but 4.1.19, which also experiences the bug has an identical files to 4.1.17 (which doesn't experience the bug). In other words the issue appears to be unrelated to these files. | ||||
| Steps To Reproduce | I've saved "Ghosts of Beverly drive" to the ftp server. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1864 | ||||
|
|
I tried with your file and the true is that CPU utilization with the file is higher, but it is higher only with some peaks, i.e. it stays at 1% and then it peaks to 10% for a brief moment and goes back to 1%. This peak appears every 2 seconds in avarage. I don't think it is related to id3lib, playback goes via in_wmp3.dll and looking into SVN the last change in in_wmp3.dll was in 4.1.16 (0014087 ) 1) make sure that you are using the same output plugin with all the versions (because some of them are portable and could have different config?) 2) try replacing in_wmp3.dll and in_mfaudio.dll by the 4.1.17 versions of the DLLs EDIT: Both in_wmp3.dll and in_mfaudio.dll were lastly changed in 4.1.16 so hey are probably unrelated to the issue. Rusty, try whether the issue appears with the first beta of 4.1.18 i.e. 1842 ( http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=54426&start=315#p437905 ) If not, then try in which beta it started |
|
|
The behavior started with 4.1.18.1842, and the problem occurs with 4.1.17 upon replacing MediaMonkey.exe with the MediaMonkey.exe from build 4.1.18.1842. Also, replacing the artwork of m4a tracks with hi-resolution (1000x1000) images triggers the bug when playing those m4a tracks, confirming that the bug isn't specific to mp3's. Presumably the same would occur with all formats. In otherwords, it appears that this is, as Ludek proposed, related to the Desktop Peek / Taskbar Preview functionality changes in 4.1.18. Lastly, I just want to mention that on my Windows 10 machine I don't see a seekbar in the taskbar preview thumbnail / Desktop Peek. |
|
|
As discussed offline, most probably caused by 0014251 (seekbar updating in the taskbar thumb causes CPU peaks) |
|
|
Fixed |
|
|
Tested 1861. It always generates an AV on running. |
|
|
Fixed |
|
|
Re-opened: It seems that there is a regression related to this fix. User is reporting that 30% of songs don't show taskbar artwork preview in 4.1.20 : http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=89107 EDIT: The duration bar lost issue on Windows 7 fixed in 1864. |
|
|
Fixed seekbar on Win7 |
|
|
Fixed |
|
|
Verified 1864 left resolved for second verification |
|
|
Confirmed by the user: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=89107&sid=3a5c49deefdbb6759ca42b0754a53469#p442384 |
