Not as far as I know, I recently did the same thing, relocated all my media from my external to my internal laptop hard drive, relocating each file was a painstaking process, in the end I did it over a couple of weeks, one playlist at a time.
Library File Maintenance
Short question: Is there a way to bulk 'relocate' library files that have been renamed?
Long winded: I've about 2500+ tracks, and have updated my workflow to the point where it makes sense to go with a simpler file naming convention. Historically, I've packed most of the tag info into the filename (using tag&rename) and I have a library in .aif for the CDJs and a library in .mp3 for doing off-line set lists in mixmeister. The reason I went with verbose filenames was due to mixedinkey not supporting FLAC (works now, thanks!) I've also written a couple of tools in perl to keep tags and filenames all in sync. I've been moving genre tags quite a lot lately, which means I have to 'relocate' a few dozen to a couple of hunderd files at a time... I don't like it!
So, I'm going to terse filenames, but that means I either 'relocate' file by file, or blow the library away and have it reloaded...unless there's a better way, like a EDB search/replace tool for example. There was an interesting thread of opening up the EDB structure that went nowhere out of paranoia. Perl or java would make this or other handy tools a cakewalk.
Searched in various ways for this topic, apologies if I somehow missed the thread.
Please sign in to leave a comment.
@pope > The current "relocate" tool is designed to batch-relocate files moved in the same method; in other words, if you move groups of files to an entirely new folder, or drive, that's fine. But in your case, it sounds like the files themselves are being renamed and moved individually. My suggestion would be to try and get all that work done prior to the track's first import -- if not, then a full rebuild could possibly be faster / less work, but then you also risk losing data associated with the track (cue points, loops, hotcues, etc).
ayup, that's what I figured. Like I say, releasing an unsupported API or db struct would enable the user base to solve their own particular issues as they see fit. The unsupported aspect removes risk from pioneer, everyone gets what they want.
I am resigned to just nuking the database and updating playlists on a demand basis.
As a side note, it is highly annoying this concept of 'cue memory' being global to the library. I'd like a set of default cues for the library, but would highly appreciate dedicated cue blocks for each playlist. Like I can remember which cue point goes with which set after two weeks;) The only way I've figured out how to make this happen is to have a master library, then export the playlist into an empty library representing that playlist. Now those cues are dedicated. At issue is the fact it eats much more space on a thumb drive since tracks are unique to a playlist. messy...
Tracks are not unique per-playlist; if you have one track appearing in 5 playlists, you only wind up with 1 copy across all 5 playlists.