Bug description:
I have two files which show a peculiar behaviour. They are reported as missing in Lexicon, but the file path is correct. If i use find lost files to relocate it, it tells me that “This track is already in your library”, however the only instance in the library is the track which is “missing”. Bot files contain UTF8 characters in the filename (Spanish accents). Maybe that has something to do with it. They should actually be in the upload I did for the desyncing multiple beatmarker bug.
No Habrá Nadie En El Mundo (DJ OOO Remix)
Un Año (Bachata Version)
Step by step to reproduce:
I cannot recreate this with new files, there are only two files in my library which I think I renamed and relocated before the problem appeared. I’m uploading both files after submitting this report.
Screenshot:
If this is about a DJ app, please also add screenshots of the problem in that DJ app.
If the missing track is in your library, then it is already in your library. Have you tried right clicking the missing file and relocating that one to the correct file?
yeah, that’s exactly what I did. When I click Relocate and then select the file (it even shows me the file directly because it loos in the right directory) it tells me it’s already in the library. So the Filepath is 100% correct, but lexicon says it doesn’t find the file. So in this instance, Relocate doesn’t work. It has worked several times before.
Apologies, let me be more clear:
I have two files in my library that suddenly are missing (the two files from above) These are distinct files with the same problem, I don’t want to relocate one to the other. Missing in this case meaning:
There’s a red triangle next to the file
BUT the path to the file is 100% correct
I still can’t play it
So if i right click and click “relocate”, a dialog pops up, showing the file. If I select it, lexicon throws an error “This track is already in your library” - which makes sense, since the new and the old path are identical.
I have seen such issues with UTF8 Filenames in my own projects, if string comparison is not encoding-safe. That’s pure conjecture of course.
It is probably to the accent characters yeah, but LXC does handle them nicely.
The original path with the original accents is stored and that is where LXC looks for the file. But you’re saying the path is 100% still correct but does show as missing in LXC. What I’m thinking then is that somehow that accent character went from the single character version to the double character version (or vice versa), they look identical.
Can you confirm if this is what happened? In your database the Habra track has the following double character accent:
If you copy paste the accent character from the filename on your disk right now and enter it into unicodelookup.com then I suspect it will give you the single character version.
So I went and did some testing. And I’m pretty sure that Unicode filenames cause issues. For ease of reading I’ll call all umlauts, accents etc. just accents.
To set the stage again, I am using a Windows PC and a Mac Notebook. Both are synced via a sync tool. This has historically worked fine for serato dj, engine dj and several media players. The following are my observations.
Filenames with accents get converted to the double character version in mac pathnames if manually entered. Even if I paste a single character version into the path, after copying it again, it’s a double character version.
However, programs can apparently force writing single character versions, but don’t do so necessarily. I.e. If I use Jriver to automatically rename a file, the two character version is used on mac, even if the single character version is in the metadata, while my sync program copies the version from windows.
On Windows, there doesn’t seem to be a consistent rule, but unless I copy it in, windows seems to prefer single character versions.
Accordingly, there are several filenames that have a path that differ in Unicode characters only between my windows and my mac copy
However, most programs seem to work with the differences just fine somehow. For example, Serato just recognizes the file on both systems when I drag it into serato myself. The same goes for engine Desktop, JRiver Media Center, my Sync Program (Synology Drive), rsync, MusicBee and MediaMonkey.
However, LXC does have that problem only one way apparently. If I add files on the windows machine (single character), LXC has no problem with the double character filepath on mac. If I add it on mac, LXC cannot find the file on single character windows.
Additionally, files that have been added on a mac cause problems when using LXC to export to DJ Programs.
7.1. If lexicon exports such a file to serato, serato is not able to read them on both systems anymore, only finding them on mac. (see point 5: If dragging the file into serato manually from mac, serato deals with the filenames just fine)
7.2 if metadata fields that are used for mapping the pathnames for an engine USB Stick export (artist, album, title) contain double character fields, engine can’t find them after the export if that export was performed on windows. This is not a problem when exporting from mac. Frankly, this one leaves me clueless.
Sorry for the wall of text, but this is the best I have on this problem.
TL:DR: As far as I can see, if LXC saves a song with a single character path, all is fine. If it first encounters it with a double character version, problems arise.
Edit: So for now, my workaround is “only add files to LXC on Windows, and all is dandy”.
