© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
OK drilled down to the root cause here. It's kind of silly.
The summary for anyone interested is:
1) Tracks generally only get a BeatGrid beat object if they have a detected BPM.
2) If you reload a track metadata, it sets the track BPM to 0.
3) The BeatGrid listens for this event and sets itself to whatever BPM the track is set to have.
4) A BeatGrid thinks having a BPM of 0 is an invalid case (well, it kind of is) and will return -1 for BeatGrid::getBpm() instead of 0.
5) When saving a track, TrackDAO checks if the track has a beat object and if it does allows it to override the bpm property saved in the 'bpm' column in the database for the track. Because of #4, this value is saved in the database as -1.
6) Once the track is expired from the track cache, the BaseTrackCache goes and looks up the fresh data for the track in SQLite. This BPM for tracks that have this happen to them will be -1.
It seemed to appear at random because of the dirty track cache. Every time you load a new track, the 5th most recent track you loaded is expired from the dirty track cache. So that's why unrelated tracks seemed to be switching.