Well, I have same issue.
I'm using 2 PC at work and at home. I need easy way to SYNC MM_DB (with Played# etc) and Music library.

So I Installed MM as Portable, DB saving absolute paths to Music Library (At Work).
Bring it to Home, SYNC and of course i got all my library greyed out. Missing Path!!! Even they all in same directory "D:\MUSIC" (Hard Disk S/N is problem...)

What will be great is Relative Path (AGAIN).
Easy thing to update
MUSIC_LIBRARY=D:\MAIN\MEDIA\MUSIC (At Work)
MUSIC_LIBRARY=D:\\MUSIC (At Home)

Many other programs using Relative paths. You can create as many as you want.
It's basically link to your library.

Many people will found this concept very useful!

[quote="Lowlander"]The user uses MediaMonkey to do this and has no problems.[/quote]

Dear Lowlander, please don't expect me to believe you that this would always work flawlessly, as even more more simple features in MM4 STILL DO NOT WORK. For example, as I have CLEARLY DEMONSTRATED in an other post, MM4 DOES save opened tabs inside its INI file but is NOT able to restore these tabs on the next program restart. And please don't tell me that in this case MM4 did not close completely, because this would imply telling me that I'm not able to read what's listed in Windows Task Manager!

I never wrote that MM4 should use drive letters to find its paths, but you still keep talking about drive letters. Relative paths are a really different concept than drive letters. The concept of RELATIVE PATH includes the OPTION to conveniently CHANGE the relative path inside the program preferences (a SIMPLE and QUICK task understood even by computer novices), where in turn MOVING 100 GB of files inside a program like MM is always a LENGTHY and ERROR PRONE process where many errors can occur, as we all know very well.

[quote="Peter Panino"] A user has MM4 Portable on an USB stick together with the database and the audio files. One day he may run out of space on the USB stick and transfer all the files onto a larger USB stick.[/quote]The user uses MediaMonkey to do this and has no problems.

However if a user uses a portable drive which may get assigned different drive letters the driveID will always work.

And relative Paths would also fail if you'd move the DB (or whatever the path would be relative to) to a different location.

DriveID works well, but forces the user to use MediaMonkey to move the files (outside moving with File Monitor enabled would work too). Drive Letters can fail when drive letters are changed and relative paths can fail when the relative position is changed. All methods end up having drawbacks, if a proper driveID recovery would be build in (automatic and just asking user for confirmation) it wouldn't be an issue at all, until then use MediaMonkey for your file moving needs.

Again, sorry that I have to say it, but this drive serial number concept IMO is so stupid that it hurts!

See this example which could be very common: A user has MM4 Portable on an USB stick together with the database and the audio files. One day he may run out of space on the USB stick and transfer all the files onto a larger USB stick. Using RELATIVE PATHS this would be absolutely NO PROBLEM: After copying the files everything works perfectly again. But with the drive serial number nonsense massive problems will start to arise: Many USB sticks will not allow to change their drive serial number, or error prone scripts to change the database will create a mess and destroy the work of years, or the user will be forced to meddling around on low level tricks by directly editing the database.

The drive serial number concept is clearly against all user interface guidelines and FORCES the user to use a concept which maybe works well for SOME users. But the user should have the FREEDOM of choice between several operating modes inside an application. So MM4 should clearly update to offer a CHOICE: Relative paths OR drive serial numbers (or a combination of both)!

Mm does not identify drives by drive letter, it uses the drive serial number.

So, yes, it works fine on portable installations.

Is there a difference with the PORTABLE version of MM4 in handling this issue? Almost ALL portable programs use RELATIVE PATHS to find their data because they often are installed on portable drives such as USB sticks which always have a different drive letter depending on which computer they are attached. And because PROGRAM and DATA reside in the same directory which is the definition for portable programs. RELATIVE PATHS are a MUST for portable programs!!

This is what I always do when transferring files to a new hard drive.
It has always worked for me. I call it my Grecian Formula.
Gets rid of all the GRAY :)

http://www.mediamonkey.com/forum/viewtopic.php?f=3&t=56574&p=291753&hilit=hard+drive+volume#p291753

In your scenario you're moving files, thus you can move them with MediaMonkey or while the File Monitor is running outside of MediaMonkey.

The DriveID method is actually very solid when it comes to managing media on portable drives. The problem with using DriveID is when drives fail and backups are used. In this scenario you'd be stuck using the change DriveID script. In all other situations a solution is available like using MediaMonkey to move files or using the File Monitor to track file moves outside of MediaMonkey. Even if a user fails to use either method there is the Located Moved/Missing to help fix things.

Improving the success rate of Locate Moved/Missing would help improve things and the ability to within MediaMonkey change the DriveID (right click on drive in Location node and point to correct drive to have DriveID updated would be a quick tool) would go a long way to improve this for users.

Most users running into issues with DriveID are those who didn't follow MediaMonkey procedures for file moving. I doubt they would setup relative paths to prevent this issue from happening as they don't follow current preventative measures either.

Also see: http://www.mediamonkey.com/wiki/index.php/Moving_MM_to_a_new_computer

There's no need to change the Volume ID or anything that drastic, or use a "database tool" to make the necessary change in the database. You [i]could[/i] if you wanted to, but there is already a script that does the necessary change to the database, and is pretty straight forward. You're making this out to be far more complicated than it actually is.

Sorry that I have to say this, but this is so silly that I can't believe it! There are other methods to make a drive unique which are much easier to handle: For example, put an invisible GUID file in the root of the drive, or give the Volume a unique name, etc. Having to mess around with tools that change the Volume ID is extremely dangerous because other programs or low level settings could depend from it! And having to edit the database with a database tool is also dangerous because many users who are not programmers may accidentally damage important data!

FYI, it's set up like that because there are individuals who have their music stored on external drives. Thus, if they plug their external in first then it might be assigned to Drive G, but if they were to plug in a USB stick first, then the external, the external then might be assigned to Drive H (unless the user has taken steps to assign it a letter, like mine is M... for music, lol). This way allows the music to still work, regardless of how many drives may be plugged in and which order they are.

Like NoHitter says, there's (easy) was of changing the Drive ID in the database, so if the structure is the same then you make that small change and you're good to go.

[quote="Peter Panino"][quote="Lowlander"]The issue is with DriveID and this can be solved by Locate Moved/Missing or proposals around DriveID change handling like auto-detection.[/quote]

Does this mean that when I:
1. add a new hard-disk to my computer,
2. then copy the directory structure with the MM audio files to the new hard-disk to recreate the same directory-structure there,
3. then give the volume on the new hard-disk the same drive-letter as the old drive (of course after changing the drive-letter of the old hard-disk volume,

does it mean that this will NOT WORK because the DriveID on the new Volume is different from the DriveID on the old volume, ALTHOUGH the drive-letter and the directory-structure are the same????? Please don't tell me that this is true ...[/quote]
Yes, that's right. There are programs available so you can manually change the Serial volume number on a hard drive, or you can also just use a DB editor tool to update the serial number in the MM database.

[quote="Lowlander"]The issue is with DriveID and this can be solved by Locate Moved/Missing or proposals around DriveID change handling like auto-detection.[/quote]

Does this mean that when I:
1. add a new hard-disk to my computer,
2. then copy the directory structure with the MM audio files to the new hard-disk to recreate the same directory-structure there,
3. then give the volume on the new hard-disk the same drive-letter as the old drive (of course after changing the drive-letter of the old hard-disk volume,

does it mean that this will NOT WORK because the DriveID on the new Volume is different from the DriveID on the old volume, ALTHOUGH the drive-letter and the directory-structure are the same????? Please don't tell me that this is true ...

Yes, serial number.

[quote]The issue is with DriveID[/quote]

Which "DriveID" do you mean? Do you mean Volume Name or Device Name?

Edit: Or do you mean the Volume serial number? (Not the hardware disk serial number).