-
-
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
empty library entrys of new tracks after "Rescan libraray" #6012
Comments
Commented by: daschuer This bug is caused by the fact, that the library scanner uses its own Instance of TrackDO, which is not connected with the BaseTrackCache. The attached patch solves the bug due to rebuild the Cache after the library scanner is finished. I am not sure, whether it is worth to extend BaseTrackCache to except a TrackPointer for refreshing its index. @RJ Ryan: What do you think? |
Commented by: ywwg This is the same bug as https://bugs.launchpad.net/mixxx/+bug/868468. It's more than just the scanner -- any update to a track in the code doesn't get reflected in the UI. (although BPM detection is the only other case I can think of where this would show up). |
Commented by: rryan I've added a check in BaseSQLTableModel to ensure a track is present in BaseTrackCache (by querying for it) before BaseTrackCache::data() is called. This prevents the blank entry problem from becoming user-facing, but it is still not very efficient because it will generate 1 query per track missing from BTC. Daniel -- as you mentioned, clearing the BaseTrackCache after re-scan is also not the best solution. I'm working on adding signals about exactly which tracks are added/removed so that we don't have to do that. |
Commented by: rryan I've added signals from TrackDAO to broadcast tracks-added and tracks-removed signals but the fact that we have multiple TrackDAOs is problematic. At the same time, I don't want TrackDAO to be a singleton because then we have to make it thread safe, which would only contribute to its complexity.
|
Commented by: rryan Scanning already refreshes the library/missing tables when it completes so I don't think it's a stretch to also update the BTC and just leave it at that for now. In the future, the BTC and table models should get selective updates of what tracks the scanner changed. I committed your patch and also adapted it for the 1.9 branch. Thanks Daniel! |
Commented by: daschuer I am currently working on the selective update via TrackPointer, based on the patch from bug #801700. An intermediate step is commited into my lp:~daschuer/mixxx/daschuers_trunk. |
Commented by: daschuer Work finished, look at bug #801700 |
Issue closed with status Fix Released. |
Reported by: daschuer
Date: 2011-10-08T08:29:50Z
Status: Fix Released
Importance: Medium
Launchpad Issue: lp870544
Attachments: library_empty.patch
How to reproduce the bug:
The text was updated successfully, but these errors were encountered: