-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
library/serato/seratofeature: Fix relative paths on OSX (and on Linux) #2659
library/serato/seratofeature: Fix relative paths on OSX (and on Linux) #2659
Conversation
Unfortunately still not able to load tracks from the main Serato DB on the boot drive. Loading one from the external drive still works. Attaching a debug log where I first tried to load a track from the main DB, then from the external. |
Thanks for checking. You can right click the column headers in the serato library view and un-hide the location column to see the file path detected by mixxx. It's incorrect I assume? |
Btw, if you're not using CMake please try a clean build to make sure it builds the correct version. |
Yep, all clean all the time now - though I'm not even sure I trust that (it's scons -c, right?) because the following rebuilds complete suspiciously quickly. Unhiding the location column makes all the tracks listed in the Serato library disappear, along with some scary looking errors coming out in the console. Debug log attached. |
Ouch. This query looks like it comes from BaseTrackCache. @uklotzde Any ideas what causes them? |
Ping @uklotzde |
@bengl3rt Yikes, I used the wrong ifdef. Despite OSX being a unix system, we actually only set the |
@bengl3rt please retest |
Done and working as expected. Location column shows the correct path for files on internal and external drives, and they play and load as expected. I think a previous version of this patch, or possibly all the hopping around between different branches I've been doing, severely mangled my database so I did blow out ~/Library/Application Support/Mixxx and let it rescan everything. Upon doing that the scary SQL database error went away. |
Yay! Thanks for testing @bengl3rt! |
@@ -450,10 +450,25 @@ QString parseDatabase(mixxx::DbConnectionPoolPtr dbConnectionPool, TreeItem* dat | |||
databaseRootDir.cdUp(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is unnecessary now, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. QDir:root()
is a static method and always returns the system drive letter. I think you can move your home directory onto a different drive on Windows, right?
Is this issue still unresolved? |
I think not, although it might indicate a potential problem for users that update from 2.2. If your still have a 2.2 database lying around, it might be a good idea to check that the upgrade doesn't cause any issues. |
Fixes the path issue on OSX that was reported here: #2480 (comment)