If anyone is keeping tabs, could I just second Peter Hollin's comments. I'm trying to share the MM.DB file and running into problems because the UNC names override the drive letters. Being able to subst and point everything at D:\music (or whatever) would be tremedously, fantastically easier.

I'm a MM gold user and a network engineer.

I have to say - using the media ID is a good idea for locating physical media which may have moved around.

However;

It's tremendously counter-productive for anyone who uses a network drive or subst. Those volumeIDs change all the time. This issue has made me seriously consider no longer using or recommending MediaMonkey. The UNC solution is wrongheaded and backwards. My installation won't even work with UNC's anyway. People who use mapped drive letters do so specifically to abstract data landmarks away from the network topology. We have chosen not to use UNCs for very specific and beneficial reasons. I remember not-so-fondly having to push out registry entries to MSOffice clients to change a behavior which stupidly insist on using UNCs internally even when you have given them drive-mapped files. This sort of abstraction is vital to anyone who ever consolidates or separates servers.

The simplest solution would be not to use volumeIDs for any non-physical media. It confers no benefit on virtual drives whatsoever. This would require only the most trivial of code changes.

I would suggest going a step beyond this and also doing the following:
Even for physical media, don't rely on the volumeID until *after* you've failed to play a file. In fact, if files are successfully played and the volumeID is different, the volumeID should catch up to accommodate (possibly after a background sanity-check scan). I'm sure it would be easy to keep a list of volumeIDs on which the collection has been seen and how trustworthy each one is. If the user has relocated things in a way that is consistent with them understanding what they're doing, then the software should follow along. Even in the case of physical media, it's unreasonable to expect that the files will only ever be manipulated within MM. Sometimes hard-drives die and backups are restored. Some people use virtual machines or roaming desktops. Sometimes you need to use rsync to get the job done. Using the volumeid has its virtues - but it is better suited as a fallback than as an automatic action on startup.

Provide an easy way in the GUI for advanced users to change it. Heck, in the property panel where you can already see, but not edit, would be at least something. Better yet would be a dialog similar to the MM_HDDSerial.vbs script. It's enragingly frustrating to see it and not be able to edit it. I know where my music is. And yes, I can go into the database, but that involves decimal to hex conversions and takes some fiddling to get the hang of. People comfortable doing that are also comfortable doing a "cat /home/mp3/daftpunk.mp3 | mp3decode | /dev/snd" to play their music.

@sveintore
You can find the Script here

The script would allow you to use the same database for different harddrives as long as the driveletter is the same. Currently that isn't possible due to the US of the ID.


PS. Ratings are stored in the tags for mp3 files.

onkel_enno wrote:Wouldn't a Script be a simple solution? The only thing it has to do is to change the Serial-Number in Table Medias. I could try to prepare that, if there is any interest :wink:

Let me add my voice to the cries. However, I don't understand how a script will help in this. In my case, I've got a flaky wifi connection to a machine so I've mirrored my 100 GB collection on a seperate hard drive on that machine (call it drive M:). However, the other machines in the house access the music files via a Samba share (also mounted to drive M:). Of course, this means that the MM database for the machine with the mirrorred drive doesn't work on the other machines. So, the two sets of machines have different databases. This, of course, is a huge pain for ratings and play counts.

How does a script help here?

onkel_enno wrote:Wouldn't a Script be a simple solution? The only thing it has to do is to change the Serial-Number in Table Medias. I could try to prepare that, if there is any interest

Any way that helps me would be great.. I sync a drive at home and a drive at work, I have no problem with connecting it to the same drive letter.

So please make the script

Wouldn't a Script be a simple solution? The only thing it has to do is to change the Serial-Number in Table Medias. I could try to prepare that, if there is any interest

onkel_enno is of course right.....but only for cases in which you use *the same* drive but for some reason have a different letter.

But MM does not offer a good solution for the other way round where you have different drives but the same letter (or different letters as well).

I started the topic initially having in mind the latter cases:

Your right onkel_enno and as an external drive user I must say that this works as a dream.

But seeing the problems people users have I think MediaMonkey needs to make this configurable. Maybe even per drive. This should be moved up high on the todo list.

In My Eyes the main reason for not using drive letters is the following (not sure if it's already mentioned):
Connect an external device with an usb port -> Driver letter F
Connect the same device with another port -> Driver Letter G (might happen)

Now MM detects that the same drive has now another driver letter -> all files are accessable.

Have been using Media Jukebox up until now. Moving to MM because I can share the library.

I have all my MP3's on my main computer. Laptop connects to shared drive 'M'.

When we go away I sync an external drive with a full copy of all music. On the laptop I disconnect the mapped drive 'M', attach the external drive which has the letter 'M' and off we go.

Not being able to use drive letters with MM is going to be a pain!

But there UNC paths would be different too. So I think it would be doable. But as you said it doesn't work for drag & drop.

I see the predicament your in. Drive letter support would help you out a lot.

You might want to check into networked attached storage like Ximeta which appears in Windows as a local drive. With the current system it doesn't matter which drive letter you assign it as it uses the drive ID. This also works rather fast. For me the Ximeta has worked very well over the past years I've used it.

My new PC is an XP, 1 GB RAM, Athlon64 3200+,all HDs are 7200.

The responce time between a klick in a location tree and actual opening/expanding is sluggish and much longer through UNC paths compared to drive letters.

I can export the playlists but i can also drag&drop the tracks from them into traktor.

A script like that would probably not be so easy to create because the tracks on the playlists are from 3 different drives.

Ok, I don't use the location node for network browsing, just locally. Maybe the developers can comment on this, because this should work equally fast.

I assume you export your playlists for use with Tracktor DJ Studio? You could create a modified version of the export to m3u playlist script that would modify the path to the mapped network drive/local drive letter instead of the UNC network path. That would only leave your problem of the slow location node.

the 3 drives are on 1 PC.

What i did not mention is....

i use the playlists in other programs as well, the most important is "traktor DJ studio".
I do not know what happens but the tracks take extremely long if loaded into traktor by playlists with UNC-network paths, but there is no problem when using network paths with drive letters.

Also browsing LIBRARY/LOCATIONs is evidently more sluggish through UNC paths than drive letters. I tried it all already and gave it up.