View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008142 | MMW v4 | Install/Config | public | 2011-07-13 20:21 | 2011-09-14 22:29 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0008142: Installation via non-admin user --> failed OS integration | ||||
| Description | If 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 Information | Reported at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=59030 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1426 | ||||
|
|
Assigned back to Rusty as i can't reproduce in clean Win7 with standard user (non-admin). |
|
|
OK, upon further testing it seems that the problem is more general--on a non-clean machine, MM isn't saving file associations. |
|
|
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). |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
Maybe this happens because I have already installed MM under the admin account. |
|
|
I'm logged in as a user with admin rights. |
|
|
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. |
|
|
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 ? |
|
|
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. |
|
|
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. |
|
|
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) |
|
|
I think that solution c) is preferable. What do you think? |
|
|
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. |
|
|
Solution c) is implemented in build 1423. Leaving assigned to me in order to clarify some other issues as discussed with Rusty over IM. |
|
|
Fixed in build 1423. |
|
|
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. |
|
|
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... |
|
|
Please generate debug log while associating in the elevated mode, I should see which registry entry fails to write. |
|
|
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? |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
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) |
|
|
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. |
|
|
Verified 1432 |
