View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002439 | MMW v4 | Install/Config | public | 2006-03-30 15:25 | 2011-05-14 02:03 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0002439: Portable version of MediaMonkey | ||||
| Description | It should be possible to run MediaMonkey off a USB key. That way users could easily take their libraries with them to work/friends houses. This would require that all MM information be stored with the application (e.g. information that is currently stored in other directories, the registry, or in a shortcut to the desktop). This would consequently require either changes to our installer or a completely different installer. Suggested UI: On the 'Select Destination Location' dialog of the installer, add: [ ] Install to USB Drive (Portable mode) If this option is enabled: -default install location should be e.g. \MediaMonkey.exe (i.e. not in ..Program files) -there shouldn't be a subsequent dialog prompting for the Start Menu Folder -there shouldn't be an option to create a desktop icon -all configuration data and db info should be saved to subdirectories of the application along the lines of \InstallPath\MediaMonkey\AppData\.... Optional: U3 support (see www.u3.com), but it's not necessarily worth it in the short term if it's a lot of work vs. basic support for running MM off of a USB key. | ||||
| Additional Information | http://www.codinghorror.com/blog/archives/000939.html | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1356 | ||||
| related to | 0000107 | feedback | jiri | MMW v4 | Support for configurable library location |
| has duplicate | 0002435 | closed | jiri | MMW v4 | Ability to run MM from a USB key |
| related to | 0003173 | feedback | jiri | MMW Wishlist | Backup/restore database |
| related to | 0007520 | closed | Ludek | MMW v4 | Portable mode: stores lots of data to the desktop (instead of the portable drive) |
| related to | 0007941 | closed | Ludek | MMW v4 | Portable install uses non-Portable Extensions.ini |
| related to | 0008286 | closed | Ludek | MMW v4 | MM Portable: File associations are enabled (regression) |
|
|
This should be done along with the architectural changes planned for 3.0. |
|
|
A note for a user who made U3 version of MM installer, I'm not sure if it can be of any use: i used the free version of PakageFactory For U3 http://www.eure.ca/ its free for non commercial use but the busseness version cost $39.95 the only difference i found out was that the free version puts [U3 Build by eure.ca] and the paid for one does not. |
|
|
Just stumbled to this bug. Here is my 30 minutes thoughts: Current MM behavior (Referring to current release 2.5.5 for easier explanation): 1. can be started off the any Flash drive without problems 2. Search for %User%\my Music\mediamonkey\ and loads all info from it INI, mdb,... 3. saves all Relevant info to Registry 4. searches registry for GOLD registration MM Portable Should do: 1. can be started off the any Flash drive without problems 2. Load Ini,MDB,... from Flash drive 3. instead of registry Portable.ini should be used with Same structure 4. GOLD Issue should be left to check for registry (No controls on Licencing issues if wemake that available) as is. Free is enough to play organize without problems. 5. Ability to start in Party Mode (very very usefull) 6. Cache MDB on HDD if user chose to cache it (Speed issue for Flash drives no speed problems with external HDDs) 7. On close save Portable.INI instead of Registry Easy 100% Solution without too much work (by numbers): 2. On start MM could check for Portable Folder Inside Application folder and load INI First (In Case that user chose to have Library in different path set in INI) then check Portable.ini for FLAG To cache Library on HDD (TEMP Folder?) and if that is the case Check for cached MDB Timestamp and Owerwrite? if Older 3. Load Portable.ini instead of registry 4. GOLD issue. As we allow user to have up to three copies of MM installed if user enter GOLD licence it will be saved in registry as Licence so that our paid user have his paid version of MM (his decision where he will use his up to 3 licenses) 5. If user bring his EXTHDD to Party then this is the right feature, also party mode is more like Portable Player than Full MM UI, and users can feel much safer about their library. 6. I think this is clear enough. 7. It is Clear enough. Technical Data on few of them: 2. Can be easily made, and will also put MM in Portable Mode for reference in other steps 6. There should be msg Box to ask user to sync back to Flash on MM close I do not see the problems about that when do that right before closure of Main APP. 7. Could be easily made with assigning MemIni instead of Registry Re: Installer no need for that User Can easily copy Whole MM folder to flash drive and best solution would be that we make small command line that will create/copy all relevant info about current MM Settings (Regisrty, MDB, INI, Playlist,...) and MM Will be ready for Portable use. Let me what you think P.S. Idea is got from this Forum Topic http://www.mediamonkey.com/forum/viewtopic.php?t=18109 |
|
|
Copied from 0000107 (this really belongs here): Jiri: Since questions like 'Where do you want to install DB file' seems to me to be unnecessary in the standard MM installer, I wonder whether another portable installer of MM wouldn't be better. It would have all these things related to ini file/DB file properly configured and could even have other differences - e.g. be smaller, don't include >1 skin, etc. Rusty: I've been using portable apps quite a bit recently, given my travelling and need to use different machines. Many apps _do_ have different installers for portable versions of the app, so this is definitely a possible approach. The main issues then are: -would upgrades work? -having multiple versions of the app can complicate distribution (e.g. on DL.com we'd have MediaMonkey and MediaMonkey Portable) Let me know what you think... jiri: 06-06-07 05:28 1. It depends on how would we like upgrades to work, the easiest would probably be to make them separate applications. 2. Two versions would possibly also mean more visibility, we could e.g. make MM compatible with PortableApps.com and try to get to their suite (but it's possibly for open source apps only). rusty 06-07-07 10:46 The best approach I've seen is where the app has an option (e.g. in Tools > Options) to: '[ ] Portable mode (store DB/config in application directory)' That way the user can install MM normally, and, if they wish, change the config on the fly. I suppose, though, that the larger question is what is the best usecase for portable use. I would expect that we would want to support both of the following scenarios: a) user operates exclusively from the USB key. This case is easy to support. b) user operates from the main machine but synchs periodically (both the db and the music) with the usb key. This case would probably best be supported via some sort of Virtual Device (i.e. where MM on the main machine synchs music to the portable device and synchs the MM db on the main machine with the MM db on the device). I don't know if this is possible or not using our existing Synchronization technology, but the way I'd envision this is that in the Synchronization Options, the user could choose 'MediaMonkey USB Key' as an option. When the user synchs with a USB Key, MM would: i) synch the content ii) synch the db iii) MediaMonkey directory and config to a specified location on the USB key Do you have another idea about how scenario b) could be supported? Re. inclusion of MM in Portable Apps, that's unlikely (since it's not open source), but I do think we can do a lot of marketing regardless of how we package it. peke 06-07-07 13:47 edited on: 06-07-07 13:50 isn't this proposed almost the same as I described in bug 0002439 except Setup Flag that will open Dialog to user to select destination for MM portable (much better and user friendlier aprach)? I agree on marketing part as beside portable version it gives proof that MM is not AD/Spy/Bloat/... Application but clean and simple that leave no Artifacts. From MM design I think that 90% of feature is already in MM, but Jiri is more competent to confirm that. Edit: Think that this will also resolve at least most part if not completely bug 0001420 |
|
|
As Talked With Jiri I have Made Update to SVN with Small helper App that will add Generic Portability Feature. Note: SVN Is Updated for Backup purposes and Source investigation it is not yet finished product. Assigning to Myself for detailed Info about generic functionality. |
|
|
Things that are not yet Implemented: 1. Command Line Control to Exclude User Interaction 2. Warning if MediaMonkey Registry is Detected Restore (Install) Configuration to local PC 3. Warning that existing Backup will be overwritten 4. Auto Start MM 5. Localization 6. Installation ISS Setup Script 7. Preparing/Copying whole MediaMonkey Folder onto portable Drive |
|
|
Assigning To Jiri for Example Application Review and suggestion how to proceed next. Petr has tested it on Vista, beside that works he found that this can be very useful for Novice, Average and even some Advanced (Experts can create all that manually anyway) MM users. |
|
|
I can review this if you wish, however, it sounds as if it doesn't meet the requirements that this run in the same manner as MM. i.e. some of the limitations that you describe are rather severe for the average user e.g.: 4. Auto Start MM -- users should be able to just run MediaMonkey off a flash drive. 5. Localization -- this should work 6. Installation ISS Setup Script -- it should be integrated into the installer (eventually) 8. Gold functionality should work |
|
|
If we don't fully convert to a portable version, we can use sandox technologies: http://boxedapp.com http://www.vmware.com/products/thinapp/ http://sandboxie.com/phpbb/viewtopic.php?t=2299&postdays=0&postorder=asc&start=0 |
|
|
PortableApps.com recently released their toolkit for making apps portable: http://portableapps.com/news/2010-06-30_-_portableapps.com_launcher_2.0 |
|
|
Updated spec in description. |
|
|
Changes needed: 1. Install MM.ini and MM.DB in the MM folder. 1b. Write to the MM.ini a parameter specifying that it's a portable installation (while installing MM), so that some things can be handled differently. 2. Don't enable any associations by default. However, if user enables some, handle them normally, write to the registry. 3. Don't enable device associations support (i.e. writing this to registry) for portable installations. 4. Move as many as possible registry settings to the ini file. 4b. In case some of the settings written to registry (including plug-ins) would be harder to transform to the main ini file (e.g. because of the tree structure?), we could create a wrapper class that would redirect reads/writes of some registry entries to the ini file. Hierarchical structures could be represented by Sections using '\' characters. Alternatively, we could create a secondary configuration file, XML in this case and hierarchy wouldn't be an issue there. However, the former option seems to be easier. 5. Gold key would be moved to the MM.ini file as well. We should encrypt it, so that it isn't that easily readable. That said, I suppose that a simple XORing of the string and writing it out in hex would be more than enough for this purpose. |
|
|
1c. If portable is flag is set (1b) MM.DB should be forced within ApplicationPath. Same thing goes for Scripts/Plugins DBNAME should be Ignored 2b. Handle Associations while MM is started, remove on Close 4. Similar to using http://docwiki.embarcadero.com/VCL/en/Registry.TRegistryIniFile 5. Bug 0006440 |
|
|
Portable Apps looks nice and it looks gaining in popularity. See http://portableapps.com/news/2010-07-17_-_portableapps.com_platform_2.0_beta_5_released |
|
|
Set to 'immediate' so that we can add the string now, even if we don't add the feature in v4.0. |
|
|
Rusty, I agree that we should add the appropriate strings to translation so that we could add this feature whenever. So is the string "Install to USB Drive (Portable mode)" the only one needed? |
|
|
I'm guessing Informational Dialog would be useful too: "MediaMonkey is starting in Portable Mode. [] Do not Show this again." I'm gussing this as MM speed will be variable due the device MM resides and users should be noted about that. |
|
|
I don't see a need for the string suggested by Peke (I use Portable Apps almost exclusively, and have never seen anything like that). If we want to play it safe, split the strings i.e.: Install to USB Drive Portable Mode (that we we can use 'Portable Mode' as an indicator, if required). |
|
|
You are right Rusty, As alternative we can supply Splashscreen that contain "Portable" text which will cover that and it does not need any additional coding. |
|
|
Incorporated the two strings: "Install to USB Drive", "Portable Mode" to be in language translations. Lowering to urgent... |
|
|
The implementation has been completed (tested on several PCs with MediaMonkey installed on a single USB stick), just UI needs to be added into the installer. So do we want to add this to MM 4.0? |
|
|
As alternative we could just add new command line parameter called /Portable that would run MM in portable mode? |
|
|
I'd like to include the option in MM 4.0. |
|
|
Updated installer for portable installation. Also changed the text to 'Install in portable mode' as folder selection is on user so word 'USB' in original text can be confusing (also added new strings in updated install.po). |
|
|
Fixed in build 1352. i.e. MediaMonkey in portable mode: - stores INI values to MediaMonkey.ini located in the install dir - stores registry values to MediaMonkey.registry located in the install dir (gold key is encrypted here) - stores database values to MM.DB located in the install dir - stores Now Playing values (in relative paths form) to MediaMonkey.m3u8 located in the install dir - doesn't associate anything from installer and after the first time run there are only already associated extensions suggested to associate - doesn't allow to install scripts/plugins into user folders, but always reads only the scripts/plugins located in the install dir |
|
|
There are some plug-in settings stored in regsitry - e.g. in d_iPod.dll. It should get info from MM.exe (probably a COM property) that it's a portable installation and store data using the same scheme as in MM.exe. |
|
|
Tested 1355, by installing MM portable to a USB drive, and noticed a few issues: 1)a) The MM library was loaded from the regular installation of MM! MM Portable should have prompted me to scan my drives and create its own DB on the USB drive. b) The Installer skipped the related step of prompting for file associations (even though none should be enabled by default). 2) DB is stored to the .exe's directory. I would suggest that everything that would normally be stored to the roaming directory be stored in a single e.g. profile directory in the mm portable directory. 3) Attempts to install the MM4 codec pack failed. |
|
|
The device plugins registry handling issue is fixed in build 1356. |
|
|
1)a) I couldn't reproduce, but I found a possible reason for this that I fixed in build 1356. 1b) Yes, this is consistent with 0006465. The installer no longer prompts to associate extensions, but this prompt is offered on first time run. In portable mode, all is unchecked. 2) OK, it is moved from .exe's directory to .exe's directory/Portable/ 3) I couldn't reproduce, in portable mode installation of addons proceeds same way, but '[ ] Install for current user only' checkbox is unchecked and disabled so everything is installed to the .exe's subdirs |
|
|
Verified 1374 |
