View Issue Details

IDProjectCategoryView StatusLast Update pluginInstall/Configpublic2014-10-28 18:22
Status closedResolutionfixed 
Product Version 
Target Version1.0.2Fixed in Version1.1.0 
Summary0008182: Portable mode: OS integration settings aren't saved and some plugins fail (MM Com Server not registered)
DescriptionWhen MM is installed in portable mode on a system (and no previous standard installs have been made), MM COM server is not Initialized correctly and External Scripts can't find "SongsDB.SDBApplication" Object and fail to initialize.

Equally importantly, changes to OS integration settings that rely on the MediaMonkey Elevator, do not persist.

Simple Example Script is Submitted.

1. WorkAround is to install MM as Non Portable and than use it as Portable.

2. MediaMonkey.registry Should Contain MM COM and Register them On MM start

3. Register MM COM on Install Even in portable Mode and make Small internal Cleanup App or Add/Remove them on Each MM start.
Additional InformationTicket: WQN-420204
TagsNo tags attached.
Fixed in build30


related to 0009423 closedLudek MediaMonkey (current) Portable isn't fully Portable 
related to 0009602 closedpeke MediaMonkey (current) Elevation needed options (UAC Prompt) 
related to 0009508 closedLudek MediaMonkey (current) Additional routine When loading Plugins 
parent of 0009429 closedpeke MediaMonkey (current) Last,fm scrobbler crashes MediaMonkey 
related to 0009454 closedpetr MediaMonkey (current) Provide workaround to allow Portable mode to use plugins that rely on MM COM Server 



2011-07-23 00:03


VBScript Error.vbs (59 bytes)


2011-07-28 11:54

developer   ~0026989

Last edited: 2011-07-28 22:54

View 3 revisions

After Talk with Petr it really seams Logical that MM do not register Server Apron install as Portable. But we need to inform users about restrictions involved using MM as Portable especially that it Break Scripting/Plugin ( functionality.

Additionally it should be best solution that MM portable Users can manually Register/Unregister MM COM server or set it to register Apron MM startup and Unregister it on MM shutdown or manually if needed.


2011-12-27 15:36

administrator   ~0029640

MM registration on startup isn't a good idea, mainly because Admin rights would be needed.

Since is probably the only important example of an add-on having a problem with this, it should be fixed. It could e.g. have an auto-script that would get SDB object and wouldn't need to create its instance manually.


2012-06-15 00:26

developer   ~0031377

Last edited: 2012-06-15 00:27

View 2 revisions

Would it be too complicated that MM Portable installation include two .bat Files and allow users that install MM in Portable version be able to register/unregister MM COM server and that they reside in MM installation folder?

MMRegisterCOM.bat "MediaMonkey.exe /elevate /regcomserver"
MMUnRegisterCOM.bat "MediaMonkey.exe /elevate /unregcomserver"

Simple Knowledgebase article would cover all other issues.


2012-06-15 14:24

administrator   ~0031378

Last edited: 2012-06-15 22:21

View 4 revisions

a. An alternate approach would be to add a checkbox to the OS integration dialog for [ ] Register MediaMonkey to Windows (help: Needed for certain addons to function correctly)

b. And/or, I'm not sure if this is possible, if an addon relies on MM COM Server, MM should prompt:
This addon requires that MediaMonkey be registered with Windows. Do you wish to proceed?

c. Or better yet, why not include a switch within the addons framework that allows scripts to prompt for a MediaMonkey restart with the elevate/regcommeserver switches?


2012-06-15 22:16

developer   ~0031380

Last edited: 2012-06-15 22:18

View 2 revisions

a. I would delay this for 4.1 especially as it is only needed for MM portable and no usage in regular version which register COM on install, it also adds new strings for translation whereas two simple BAT files do not need any CORE changes Just KB Article and its presence in portable installation folder and are BUG RISK free and can be made IMMEDIATELY for 4.0.6.

b. I think it is not be possible as error occur when Script/Plugin/External app calls Windows COM for MM and Windows itself return ERROR.

c. Jiri Implemented something Similar into MM native plugins and was never documented for public use, also there is no standard/solution for external apps to do that. This is something I was thinking about for some time and would open new bug about better Plugin Developer friendliness.


2012-06-18 17:51

administrator   ~0031392

I've modified the description to include other issues that are triggered by this deficiency (the fact that OS integration settings aren't saved in Portable mode).


2012-08-30 19:47

administrator   ~0031739

Last edited: 2012-08-30 23:39

View 4 revisions

As for the suggested approaches, an ordinary script couldn't use b. or c., since there's no way how to let MM know about this. Option a. would be possible, but I'd rather avoid introduction of a new option, particularly since it wouldn't help users until they found it and turned on.

For that reason, I think that the best solution is the one I already proposed in 0008182:0029640 , i.e. to modify script to receive SDB object instance.


2012-08-30 23:42

developer   ~0031746

Last edited: 2012-08-30 23:48

View 2 revisions

As soon as 0009508 gets resolved I'll make changes to plugin and solve this.


2014-04-24 21:27

developer   ~0040103

Added Portable functionality in v1.1.0.30 which should be used with MMW 4.1.1+ User of <4.1 should use old plugin.


2014-10-28 18:22

administrator   ~0040836

Verified build 38.