View Issue Details

IDProjectCategoryView StatusLast Update
0008142MediaMonkey 4Install/Configpublic2011-09-14 22:29
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version4.0 
Target Version4.0Fixed in Version4.0 
Summary0008142: Installation via non-admin user --> failed OS integration
DescriptionIf a non-administrative user installs MediaMonkey, even if they enter the admin password when prompted by Win 7, the app gets installed, however, file associations and autoplay features do not get configured!

Tested on Win7
Additional InformationReported at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=59030
TagsNo tags attached.
Fixed in build1426

Relationships

related to 0008286 closedLudek MM Portable: File associations are enabled (regression) 
related to 0008476 closedpetr Issues re. first run in Elevated mode (D&D problems, etc) 

Activities

petr

2011-07-19 16:16

developer   ~0026908

Assigned back to Rusty as i can't reproduce in clean Win7 with standard user (non-admin).

rusty

2011-08-18 01:59

administrator   ~0027248

OK, upon further testing it seems that the problem is more general--on a non-clean machine, MM isn't saving file associations.

rusty

2011-08-18 15:13

administrator   ~0027257

And further testing shows that installing Winamp _does_ correctly associate filetypes. i.e. it appears that there's a bug with file associations (at least in certain Win7 environments).

rusty

2011-08-19 19:16

administrator  

bug8142.LOG (173,867 bytes)

rusty

2011-08-19 19:18

administrator   ~0027267

I've posted a debug log that shows what happens when a change is made to the options panel and saved (~ line 1500). After this action was taken, and MediaMonkey was closed, double-clicking an MP3 file did not run MM.

Ludek

2011-08-22 13:27

developer   ~0027284

Last edited: 2011-08-22 13:34

View 3 revisions

I am able to simulate this problem when I am logged on the Guest user account with poor user rights. Which account you tested?
But the Guest account doesn't allow to install a program. Maybe we should add an error message that user needs to be logged as administrator to change file associations/handlers. Similarly if a user wants to install MM from the guest account then it tells him that he needs to be logged as admin.

Ludek

2011-08-22 13:44

developer   ~0027285

I am able to replicate this also with the Standard user account, but the Standard account also doesn't allow me to install MM, it says that I need to be logged in as administrator. Also when I right-click the MM installer and select 'Run as administrator' it still says that I need to be logged in as administrator. Do you experience the same?

Ludek

2011-08-22 14:44

developer   ~0027286

Maybe this happens because I have already installed MM under the admin account.

rusty

2011-08-22 15:33

administrator   ~0027290

I'm logged in as a user with admin rights.

Ludek

2011-08-23 14:15

developer   ~0027302

Last edited: 2011-08-23 14:23

View 4 revisions

After some investigation the issue of mine was caused by a non-default settings.
My 'User Account Control Settings' was set to 'Never Notify' instead of 'Default'
Once I changed it to 'Default' and restarted computer then installer prompted me to enter admin's password. Once I entered the password MM was installed successfuly and extensions have been associated.

So the issue is that MM doesn't associate extesions on the 'Standard user' account if it is not 'Run as administrator'. But hard to do something about this, MM simply doesn't have enough rights to re-associate the file extensions. We should add a tooltip, that OS integration works only if MM is run as admin or with the /elevate command.

rusty

2011-08-23 15:45

administrator   ~0027305

My user account control settings are set to 'Default'. Moreover, other apps such as winamp work correctly.

Would it help if I provided a copy of portions of the registry before/after install of Winamp and the same for MM ?

Ludek

2011-08-23 16:11

developer   ~0027306

Last edited: 2011-08-23 16:16

View 4 revisions

I don't fully understand what the issue is for you.

1. Do you say that it doesn't associate even when you install MM?
2. And does it associate if you run cmd and type 'MediaMonkey.exe /elevate'?
3. I attached screenshot of the default security settings, please run 'gpedit.msc' and check whether you have the same settings. Note that only the lines with leading 'User Account Control:' are interesting.

Ludek

2011-08-23 16:12

developer  

Untitled.jpg (713,133 bytes)

rusty

2011-08-23 18:25

administrator   ~0027307

1. Yes. If I uninstall MM3/MM4, then file associations changes to 'unassociated'. If I then install MM4 (note: during the install, UAC prompts to elevate rights), file associations remain 'unassociated' after the installation, even though most common media file types should be associated with MM at that point.

If I run MM again, files remain 'unassociated'.

2. If I then run MM as 'Administrator' video file types get associated, but Audio file types do not.

This makes me wonder if there are actually 2 bugs:
 a) MM doesn't actually set file associations
  i) on first run because it doesn't elevate rights on first run
  ii) when changes are made to OS config because it doesn't automatically elevate rights upon changes to the OS config.
 b) Even when rights are elevated, MM doesn't correctly update the registry for file types that had been previously dissassociated upon uninstall of a previous version of MediaMonkey.

3) See attached.

rusty

2011-08-23 18:25

administrator  

local_policies.jpg (385,985 bytes)

Ludek

2011-08-24 10:06

developer   ~0027314

Last edited: 2011-08-24 10:22

View 4 revisions

To understand what happens.
1. When MM4 is installed then the installer associates all the extensions that are unassociated (aren't associated with any program).
2. When MM is run first time then the 'Welcome to MediaMonkey' wizard is shown and it also offers to change the associations and here is the bug. As you pointed MM is not elevated on first time run
=> Fixed in build 1423.

The remaining issue is that MM doesn't automatically elevate rights upon changes to the OS config. Hard to do something about it, because MM cannot elevate rights when it is running, it needs to be run again with the elevated rights.

There seems to be 3 solutions:

a) Always run MM in the elevated mode (so that also re-associate on startup feature works), but this would be very annoying and limitating to always run MM in the elevated mode.

b) Somehow inform user that changes to file associations can be made only when MM is running as admin or with the /ELEVATE command line param.

c) Whenever a change is made to 'OS integration' panel, MM would require restart and the changes would be applied on the next startup (in the elevated mode)

Ludek

2011-08-24 10:26

developer   ~0027315

Last edited: 2011-08-24 10:26

View 2 revisions

I think that solution c) is preferable. What do you think?

jiri

2011-08-24 13:29

administrator   ~0027318

c) sounds good, particularly if we add '(requires restart)' string there. In case we can easily detect the current MM mode, we could also do it conditionally, i.e.:
1. If MM is elevated (or elevation is not required on older systems) - apply the changes immediately.
2. If MM needs elevation, show the string, save changes and apply them after MM restart.

Ludek

2011-08-24 16:19

developer   ~0027326

Last edited: 2011-08-24 16:28

View 3 revisions

Solution c) is implemented in build 1423.

Leaving assigned to me in order to clarify some other issues as discussed with Rusty over IM.

Ludek

2011-08-24 22:36

developer   ~0027333

Fixed in build 1423.

rusty

2011-08-29 21:52

administrator   ~0027406

Last edited: 2011-08-29 22:03

View 4 revisions

Tested 1424 and MM still fails to associate correctly on this machine.

When I implement associations manually via Windows, it works as expected.

Edit: to clarify: even on installing MM (rights are elevated), MP3 files do not get associated with MM.

Edit2: interestingly upon manually associating file types (e.g. Flac with mediamonkey--see attached image), MediaMonkey is listed by default as a preferred application for the given filetype even though it isn't actually associated. i.e. MM is presumably updating some registry entry that makes it 'preferred' for a filetype, but isn't actually making the association--that must be done manually.

rusty

2011-08-29 22:00

administrator  

file_association_flac.jpg (182,590 bytes)   
file_association_flac.jpg (182,590 bytes)   

rusty

2011-08-29 22:05

administrator   ~0027407

Possibly related issue (double-click of tracks in Win Explorer causes MM to move them?!?): http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=60025

not replicable...

Ludek

2011-08-29 22:56

developer   ~0027409

Last edited: 2011-08-29 23:02

View 3 revisions

Please generate debug log while associating in the elevated mode, I should see which registry entry fails to write.

Ludek

2011-08-30 14:22

developer   ~0027414

Last edited: 2011-08-30 14:57

View 9 revisions

Note that I reproduced something similar if I manually changed association for WMA (in Windows 7) from MediaMonkey to WMP. Then I couldn't change it back neither by MediaMonkey and neither by RegEdit because of the value

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.WMA\UserChoice\Progid = WMP11.AssocFile.WMA

the value cannot be changed also by using RegEdit. It looks that user choice has some preference while there is still value
HKEY_CLASSES_ROOT/.wma/(Default) = MediaMonkey.WMAFile

A clue could be here: http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/630ed1d9-73f1-4cc0-bc84-04f29cffc13b
where to be able to write to the key UserChoice he needed to take ownership of the key before writing to it. He used code from the following link: http://www.tomshardware.com/forum/170289-46-programmatically-inheritable-permissions
but it looks more like a hack.
It also seems to me that we shouldn't steal the associations that user made manually?

rusty

2011-08-30 14:56

administrator  

bug_8142_install_log.zip (323,182 bytes)

rusty

2011-08-30 15:32

administrator   ~0027416

I've attached a new log, along with copies of the registry taken:
a) after MM has been installed (with failed associations
b) after manually associating MP3 and FLAC. Note that after manually associating MP3 and FLAC, then OGG 'magically' became associated with MM!!

Here are my observations after performing step a)
Ogg, MP3, :
- Not associated with anything (i.e. no icon. Double click --> Choose the program you want to use to open this file: (same apps as 'Open with')
- Context menu: Play in Winamp, Enqueue in Winamp, Add to Winamp's Bookmark list
- Open with: Irfanview, MediaMonkey, Quicktime Player, Windows Media Player, iTunes, Mp3Tag, Windows Media Center

Flac:
- Not associated with anything (i.e. no icon. Double click --> list of almost all installed apps with associations
- Context menu: Play in Winamp, Enqueue in Winamp, Add to Winamp's Bookmark list
- Open with: list of almost all installed apps with associations

Have a look at the registry files...it's really strange how they appear very differently depending on whether they were updated by MediaMonkey, or Windows.

rusty

2011-08-30 15:33

administrator  

Ludek

2011-08-30 21:48

developer   ~0027419

Last edited: 2011-08-30 22:08

View 5 revisions

MP3:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.mp3\UserChoice\ProgID
is only one of 3 locations where windows associates given extension.
For MP3 it seems to be correctly associated with MM, so I would need to see values of these 2 registry paths also:
HKEY_CLASSES_ROOT\.mp3\(Default)
HKEY_LOCAL_MACHINE\Software\Classes\.mp3\(Default)

OGG:
Strange thing is that you claim that OGG became magically associated with MM, because the ...\.OGG\UserChoice\Progid = "Winamp.File.OGG". So I guess it should open in WinAmp?

FLAC:
For FLAC the ...\.FLAC\UserChoice\Progid value changed from Winamp.File.FLAC to MediaMonkey.FLACFile after manual associating as expected.

WMA:
For WMA the ...\.WMA\UserChoice\Progid = "Winamp.File.WMA" so WMA opens in Winamp. Can you confirm?

Strange thing in all cases is that from the log I don't see an access problem for MM to write to the UserChoice\Progid. If you try ti edit the value manually by regedit, is it allowed?

Ludek

2011-08-30 22:51

developer   ~0027421

Nevertheless after some investigation I have found the root of my problems (of inability to change the UserChoice value) and fixed it in build 1425.

This most problably fixes the issues on your machine too. Give a try in 1425.

rusty

2011-08-31 04:35

administrator   ~0027422

Tested 1425 and the situation is _much_ better but not completely solved.

Now the following occurs:

1 Run MM installer
--> MM installs, and at the end prompts the user whether to run MM.
2 User chooses to run MM
--> Wizard prompts user for various items including associations
3 Close MM and verify whether file associations have been implemented
--> They haven't
4 Run MM
--> MM automatically escalates and implements the file associations correctly

Although this is implemented according to Jiri's suggestion, the problem is that a user installing MM expects file associations to have been implemented after step 3, but they aren't. Could this be solved by either:
a) having MM run with escalated rights right after install
b) having MM escalate rights after configuring associations (that's what Winamp does)

Ludek

2011-08-31 10:26

developer   ~0027424

Last edited: 2011-08-31 10:26

View 2 revisions

Note that it was already implemented by using solution (a).
If MM is first time launched outside of the installer then it works in build 1425, but it doesn't work if MM is launched directly from installer.
=> Fixed in build 1426.

peke

2011-09-14 22:29

developer   ~0027717

Verified 1432