View Issue Details

IDProjectCategoryView StatusLast Update
0014596MediaMonkey (current)Otherpublic2018-01-23 11:18
Status closedResolutionfixed 
Product Version4.1.18 
Target Version4.1.20Fixed in Version4.1.20 
Summary0014596: High CPU utilization during playback (regression)
DescriptionI 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%

- 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 ReproduceI've saved "Ghosts of Beverly drive" to the ftp server.
TagsNo tags attached.
Fixed in build1864


related to 0014251 closedpetr Taskbar Thumbnail Distorted on Windows 10 Creators Update 
related to 0014490 closedLudek CPU utilization at 50% 



2017-12-21 20:38

developer   ~0049449

Last edited: 2017-12-21 21:04

View 4 revisions

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 ( )
If not, then try in which beta it started


2017-12-21 22:00

administrator   ~0049450

Last edited: 2017-12-22 00:46

View 2 revisions

The behavior started with, and the problem occurs with 4.1.17 upon replacing MediaMonkey.exe with the MediaMonkey.exe from build

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.


2017-12-21 22:13

developer   ~0049451

Last edited: 2017-12-21 22:46

View 2 revisions

As discussed offline, most probably caused by 0014251 (seekbar updating in the taskbar thumb causes CPU peaks)


2017-12-22 11:56

developer   ~0049452



2017-12-22 13:52

administrator   ~0049453

Tested 1861.

It always generates an AV on running.


2017-12-22 17:12

developer   ~0049457



2018-01-11 11:56

developer   ~0049505

Last edited: 2018-01-11 20:00

View 2 revisions


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 :

EDIT: The duration bar lost issue on Windows 7 fixed in 1864.


2018-01-11 20:02

developer   ~0049508

Fixed seekbar on Win7


2018-01-14 19:39

developer   ~0049511



2018-01-17 02:48

developer   ~0049533

Verified 1864

left resolved for second verification


2018-01-23 11:18

developer   ~0049552

Confirmed by the user: