empty library entrys of new tracks after "Rescan libraray"

[mixxxbot]

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:

• delete ~/.mixx/.mixxx/mixxxdb.sqlite
• start mixxx
• select "Rescan library" from "Library" menu
• now you have a complete list of tracks in library view, but with empty collums
• text appears if you try to play a track or if you open the track preferences
• After restart, all tracks are appearing as desired

[mixxxbot]

Commented by: daschuer
Date: 2011-10-08T08:54:46Z
Attachments: library_empty.patch

---

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.
It seems to me not a high performance solution, because the BaseTrackCache queries all the information from the database which was already in memory just before.

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?

[mixxxbot]

Commented by: ywwg
Date: 2011-10-08T12:59:06Z

---

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).

[mixxxbot]

Commented by: rryan
Date: 2011-10-12T05:27:02Z

---

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.

[mixxxbot]

Commented by: rryan
Date: 2011-10-12T05:43:51Z

---

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.

I'm up in the air about how to fix this well. Right now, I'm leaning towards this: The LibraryScanner should re-broadcast the scanner TrackDAO's tracksAdded(QSet<int>) signal and this signal should be hooked up to the "default" BaseTrackCache's "tracksAdded(QSet<int>)" slot. Using a QueuedConnection will send the set by way of the Qt event loop so threading doesn't have to be taken into account -- and this way the BTC only selectively caches the tracks instead of re-indexing the whole library when the scanner is done. 

[mixxxbot]

Commented by: rryan
Date: 2011-10-19T16:48:59Z

---

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!

[mixxxbot]

Commented by: daschuer
Date: 2011-10-19T19:52:32Z

---

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.
There is just still the problem that moved tracks are not updated yet.

[mixxxbot]

Commented by: daschuer
Date: 2011-10-21T22:42:46Z

---

Work finished, look at bug #⁠801700

[mixxxbot]

Issue closed with status Fix Released.