lol!

I'd actually expect the portable flat file to be faster than the registry. This is often cited as one of the reasons that Wine runs Windows programs faster than native.

Might there be a speed difference? Wouldn't accessing the Registry be faster than accessing a file for the settings?

I don't see any disadvantage to installing it portable. The only thing to keep in mind is that the default Portable install doesn't enable some of the OS integration that's enabled by default with a regular install (i.e. file associations, auto-play actions, Explorer context-menu integration), but you have the option of enabling those at install or via Tools > Options > General > OS integration.

I personally prefer running all my apps as portable apps--that way I can take them with me.

-Rusty

OK, so not good for multi users. End of!

Are there any disadvantages to installing as Portable? Why not make it permanent?

Portable install isn't a good way to run in a multi-user environment, because it stores everthing (including registry) in MM install folder. This implies that it shares also toolbar/form positions or visibility (stored in the registry) and so on.
It could be a way for a single user who wants to access its MM instance from multiple machines, but he needs to be careful to run the instance exclusivelly on multiple machines. Adding a semaphore could be rather dangerous, because if MM would be closed unexpectedly (e.g. because of a blockout) then it wouldn't allow to be run next time.

markstuartwalker wrote:With portable mode the registry information is stored in a file rather than the registry.

Normal mode will store registry information in the registry of each of the that use the executable.

The device plugins use the registry for some of their configuration.

So ultimately no difference, then?

With portable mode the registry information is stored in a file rather than the registry.

Normal mode will store registry information in the registry of each of the that use the executable.

The device plugins use the registry for some of their configuration.

markstuartwalker wrote:
All you do is install to a network share and then point a shortcut on each machine to the Exe in the share.

How's that any different/better than just doing the exact same with the regular installation?

nohitter151 wrote:

markstuartwalker wrote: Please can we have a formal statement from the MM developers about the adoption of Portable for multi-machine usage. Particularly about concurrent access from different machines.

What exactly are you asking about? I don't think with MM4 that anything will have changed since this KB:
http://www.mediamonkey.com/support/inde ... 68&nav=0,3

I also fail to see how installing in portable mode would be beneficial in multiple PCs and 1 db.

Portable mode is a simpler way of achieving http://www.mediamonkey.com/support/inde ... ticleid=49

All you do is install to a network share and then point a shortcut on each machine to the Exe in the share.

markstuartwalker wrote: Please can we have a formal statement from the MM developers about the adoption of Portable for multi-machine usage. Particularly about concurrent access from different machines.

What exactly are you asking about? I don't think with MM4 that anything will have changed since this KB:
http://www.mediamonkey.com/support/inde ... 68&nav=0,3

I also fail to see how installing in portable mode would be beneficial in multiple PCs and 1 db.

I think that the Portable option is being considered for uses beyond it's design. It was created to allow MM to be located on a removable drive that could be hiked around onto various machines. Implicitly there is no consideration for simultaneous use.

By installing MM on multiple machines and configuring their INI files to use the same DB you can modify the DB from various machines and many users operate in this way. The known problems are that only the DB is shared and thus some errant behaviour is observed as some data appears to be stored outside of the DB. Further, upgrades in MM have to be done in sync across all machines to ensure that the DB upgrades happen in a controlled manner.

Portable installation seems to offer a fix for all of these problems as it naturally provides a single instance that has only one DB, one registry, one set of INI files and one set of binaries. Several people have tried this with varying degrees of determination and success.

Please can we have a formal statement from the MM developers about the adoption of Portable for multi-machine usage. Particularly about concurrent access from different machines.

willyvds wrote:I'm interested to hear which option functions better in practice if multiple PC's share 1 library:
- portable mode installation
- installation on multiple pc's (with manual copying of the .ini file)
Regards, Willy

I would assume installation on multiple PCs (not portable mode) as you're not looking for portability!

I'm interested to hear which option functions better in practice if multiple PC's share 1 library:
- portable mode installation
- installation on multiple pc's (with manual copying of the .ini file)
Regards, Willy

Thanks for your reply. It's a bit nerve racking. I'll think about firing up MM and then I have to stop and go check every machine in the house to be sure they're not running it for fear of hosing it all up again. I'm tempted to just do local installs and try to have them all use the same database.

My experience is similar to yours. I am a very careful to close MM after running it such that I never get into this scenario.

MM has a degree of muli-user capability in that the DB is transactional and so multiple users is technically quite feasible.

In practice there are other places in MM that information is stored (depending which plugins and scripts you're using) besides the database
* Local INI files on C: (soem scripts)
* Registry (some MM parts, some plugins, some scripts)
Which means that some data isn't shared between all clients. This resulted in an 'almost but not quite' multi-user experience

With MM4 portable mode the registry information is stored in the MM.registry file so that does become the same for all users. There are 2 caveats on this
* non-core MM programs might not use the MM.Registry object to write registry entries - in this case their content will not be redirected to the file
* I'm not sure how thread safe this implementation might be so simultaneous access may not work

Can anyone else comment on the last point.