Lexicon fails to import playlists containing videos (mp4 files) from VirtualDJ - the following error is seen (see the screenshot below):
Unable to Import
No tracks from the selected playlist could be found in your database
This used to work for previous versions (v0.3.26) then it was broken, then it worked again (I think v0.3.33), now it is broken again.
The error message is confusing - the files exist and were added to the VirtualDJ search database (playlist and VirtualDJ database are both attached), and the database is on an external drive.
I don’t think this is video related. This error is confusing yeah but it is a confusing problem… VDJ can delete tracks from its database but leave them in the playlist. So the playlist number on the import page shows a number, but when importing those tracks aren’t found in the database. It seems to rarely happen, not sure why VDJ does that.
I took a closer look and what is going on here is a VDJ quirk on Mac. If you look in the M3U and database file, you’ll notice there are windows file paths in it. This is (I think) a dirty workaround VDJ employs for external drives on Mac, because they started with VDJ on Windows.
The database.xml has to be on the correct external drive when importing in Lexicon, otherwise Lexicon doesn’t know which volume it belongs to because D:/ or E:/ don’t say anything on Mac. So when I use this database.xml and put it on my internal drive, it won’t work.
So I did notice that files referenced in the database.xml start with a Windows driver letter, but the m3u playlist uses proper UNIX file paths (/Volumes/{drive name})…I don’t know why VDJ developers did not correct this. Would it be ok to change Lexicon to replace the Windows drive letter with the path of the drive that the database.xml is on, if it finds paths starting with a Windows drive letter?
It does that internally yes. But the database.xml has to be on the correct drive.
This particular xml is a combined XML (maybe created from a VDJ database backup? It merges all XMLs). The combined XML has all drives in it, with D:/ and E:/ so there is no way to know what mac volume D:/ is supposed to represent. That’s the problem.
Normally the database.xml is on each drive that you have music on, with only E:/ or only D:/. For those, Lexicon internally changes E:/ to the current volume.
I think you can make it so that regardless of the drive letter, it replaces it with the actual drive that the database.xml file is on (/Volumes/{The drive}) and check if it exists. If it does, allow the import, else ignore and report it in logs/errors/somewhere else.
But what if a file exists on both drives? There is no way to know which it belongs to… File access is slow too so it would slow it down massively.
So far I haven’t seen many problems with the current approach. VDJ puts the database.xml on the right drive and Lexicon reads that.
Either the drive you are reading the database file on should take preference, or it can report an error and skip it. I agree however, filesystem access would make operations very slow…so most likely it’s better to just assume that the drive the database file is on is what Lexicon should replace the drive letter by (the root drive and all other externals have their own database file). I’m just saying…there must be some logic that VirtualDJ uses to get it right that you could replicate.
Yeah I agree. Maybe there is some kind of logic where D:/ is the first drive from some kind of drive list command, and E:/ the second, etc. But I don’t know that at the moment… We’d have to figure that out by trial and error.
How does Lexicon construct its view of VirtualDJ’s database?
If Lexicon started by looking for and parsing all the database.xml files on all known connected drives (replacing the drive letter with the actual drive path when parsing), then combining + using that combined view for the VirtualDJ database, it might be close enough to what we think VirtualDJ is doing. If you find duplicates, import them both or give an error.
Would it help at all if I just wrote a script that temporarily replaced the drive letter with the actual drive path for that external drive before running the import?
If you want, you can try that but I really can’t assist with that…
“close enough” is not an acceptable solution for this problem so I can’t do that. The way it works now is accurate but it just doesn’t work with merged databases.
I’m not really sure how VirtualDJ actually created two different drive letters in the same database - it may have something to do with me syncing then switching over to a new external SSD from an older HDD and then adding new files to the SSD (with both having being assigned different letters). The disks themselves had the same drive name (Music) when VDJ was started, and I only ever used one drive, the newer or older one, when starting VDJ. When I switched drives, I’ve never used the older one to add files, only the newer SSD. I only sync to the older one for backup.
I think in this case, it’s accurate to say all of the files listed under the database.xml for this drive are on this drive (I have all my music on that external) - I probably just have to change the drive letter to be consistent in the file (backing it up before) for Lexicon to be happy.
I know that VDJ merges them into one XML when you use the database backup function in VDJ.
I think it normally un-merges them when you put a database backup xml in Documents/VirtualDJ and then start up VDJ. Maybe you need to run the consistency check or something in VDJ to trigger it.
So I figured out what was happening. When organizing music, I connect two drives sometimes (one I use for collection of music from other DJs) to add music to VirtualDJ. VirtualDJ uses some sort of drive letter assignment internally - when the music drive is connected only, it normally gets the drive letter D. However, when the two drives are connected, sometimes VirtualDJ gives the music drive the letter E. With that said, I notice the following:
Whenever I play however, I always use the external only and it always finds the files I load.
The consistency check didn’t do anything to modify the database with corrections for this.
I tried adding a file a) with both drives connected b) with the music drive connected, then I modified the filepaths for both of them, in the database file, start with a drive letter that was opposite to what they were originally. I then opened VirtualDJ again to try to load the files - they were both found without issue.
I think this is a pretty good indication that VirtualDJ is ignoring the drive letter in the database for a song’s FilePath, and just using the database drive itself instead as the root of the filepath.
Each drive has its own database.xml, and the location of files in the database file is always with respect to that drive’s path (I think this may be true even on Windows).
Yeah I think you are right about that, that is also how Lexicon treats the VDJ database files. I think VDJ just adds the drive letter for the purpose of unique paths internally.
