View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012838MediaMonkey (current)Playerpublic2015-08-31 11:222017-10-21 20:19
PriorityimmediateSeveritymajorReproducibilityhave not tried
PlatformOSOS Version
Product Version4.1.8 
Target Version4.1.19Fixed in Version4.1.19 
Summary0012838: Play from Windows Explorer takes long time
DescriptionUsers are reporting that it takes long for MediaMonkey to start playing when a file is opened from Windows Explorer.
Additional Information [^]
TagsNo tags attached.
Fixed in build1856
Attached Files7z file icon bug_12838.7z [^] (21,675 bytes) 2017-10-16 14:10
7z file icon bug_12838_build_1855.7z [^] (25,339 bytes) 2017-10-17 16:22
jpg file icon 12838_fail1.jpg [^] (52,531 bytes) 2017-10-18 01:09

jpg file icon 12838_fail2.jpg [^] (53,740 bytes) 2017-10-18 01:09

jpg file icon 12838fail3.jpg [^] (47,460 bytes) 2017-10-18 01:09

jpg file icon 12838_when_mm_finally_launches.jpg [^] (56,234 bytes) 2017-10-18 01:09

- Relationships

-  Notes
Ludek (developer)
2017-02-23 11:19
edited on: 2017-02-23 11:21

Some additional info: [^]

Users are saying that it happens only when:
- the double-clicked track isn't in library
- when in Options > OS Integration
The "Show context-menu actions for:
is enabled.

Disabling the context actions is a workaround according to the users.

rusty (administrator)
2017-02-23 11:56

I can confirm this in

Abba - Double click when MM isn't running
--> playback starts in 8 seconds

Abba Waterloo - Double click when MM is already running
--> playback starts in 20 seconds, but may be due to podcasts downloading

ABC - The Look of Love - Double-click when MM is already running after podcast dl completes
--> playback starts in ~10 seconds

Debug log for the above posted to ftp.

In contrast: Starting playback in Clementine
--> playback starts in 3s
petr (developer)
2017-02-24 07:24

rusty (administrator)
2017-02-24 14:00

With build 1830 it takes about 25s to play a local track from Explorer in MMW. Same track takes 2-3s in Clementine.
rusty (administrator)
2017-02-24 14:16

Re-resolving. The problem went away once I restarted MM.
peke (developer)
2017-02-24 16:54

Verified 1830
Ludek (developer)
2017-10-16 13:42

Users are reporting that this is still an issue: [^]
rusty (administrator)
2017-10-16 13:53
edited on: 2017-10-16 14:09

I was able to replicate:
1 Right click 'Perfect-Alanis Morissette'
--> Error Log "Error loading type library/DLL." submitted. Description: "Attempt to 'Play in MediaMonkey' from Explorer --> Error " (around 1:44pm)
--> About 45s after the error log was sent, MMW ran and played the track

- the bug occurs when right-clicking in Explorer and MMW isn't running. If MMW is already running, then playback works correctly.
- the bug occurs consistently (i.e. restarting MMW doesn't resolve the problem).

EDIT: I replicated the bug again, this time with dbgview running.
1 Right click 'Ironic-Alanis Morissette'
--> Error Log "Error loading type library/DLL." submitted. Description: "bug 0012838" (around 2:04pm - line 45 in the log)
--> About 1:30s after the error log was sent, MMW ran and played the track
Debug log attached.

rusty (administrator)
2017-10-17 10:22

A couple of additional points:
- 'Open with'>'MediaMonkey' results in the exact same buggy behavior (again, provided that MediaMonkey isn't already running).
- 'Open with'>WMP, iTunes, Clementine all work correctly.
petr (developer)
2017-10-17 14:08

rusty (administrator)
2017-10-17 16:22
edited on: 2017-10-17 16:30

The bug still occurs with 1855:
I sent an elog entitled "bug 0012838 with build 1855"
Debugview log attached.

fyi, I just noticed something else: After right-clicking 'Play Now in MediaMonkey' then the ELog is sent and Process Explorer shows "MEDIAM~2.EXE" running at 45% CPU utilization for 90s at which point it changes to "MediaMonkey.exe" and MediaMonkey launches/plays.

rusty (administrator)
2017-10-18 01:08
edited on: 2017-10-18 01:32

Tested all the way back to MMW and the eLog error "Error loading type library/DLL" and delay in launching still occurs on this machine. My guess is that the problem occurs on such old builds because installing an old build on top of a newer one doesn't undo whatever config issue is causing this problem.

As far as possible underlying causes I wonder whether it could be related to registry changes in 4.1.18 vis a vis firewall config OR perhaps related to Portable installs on the machine of MM4 or MM5.

Note also:
-the bug occurs with both regular and debug builds
-disabling skinning doesn't solve the problem
-terminating most other apps doesn't solve the problem
-I've attached screen captures illustrating properties of the file from Process Explorer
-I was unable to replicate the problem on a Windows 7 machine

rusty (administrator)
2017-10-18 13:38

Upon further testing, I've noticed some very strange behavior:
- copy MediaMonkey.test.exe to the /MediaMonkey library, renaming mmtest.exe to MediaMonkey.exe (and MediaMonkey.exe to MediaMonkey.orig.exe), right-click play --> delay
- close MM, rename mm.orig.exe to MediaMonkey.exe (after renaming MediaMonkey.exe to MediaMonkey.test.exe), right-click play --> success!!

Once success occurs, it _always_ works until the user runs the installer to re-install MM, and then the bug starts occurring again.

Note: the process to get rid of the delay does not work consistently, however, I've been able to follow the process 3 times in order to 'solve' the bug.
petr (developer)
2017-10-20 17:13

Fixed. Actually there were 2 issues.
1. long delay before playback starts - long standing issue where first double-click on track in explorer run MM with -Embedding parameter (which runs MM DCOM server in automation mode) and for any reason, subsequent run of the same DCOM server in automation mode cause delays ... so first open is fast, but when attempting to open a new song (with MediaMonkey already running) it takes more than 30 seconds.

2. crash with "Error loading type library/DLL" - for some unknown reason GetLongFileName sometimes return incorrect (non existing, probably historical) path ... this cause crash because system cannot create DCOM server from non existing exe.
peke (developer)
2017-10-21 20:19

Verified 1856

Startup times are 3-5 Sec and subsequent starts are almost instantaneous.

Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker