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.
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.
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.
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.
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.
