rightclick on "Reload Track Metadata" gives bpm of "-1" sometimes

Bug #884696 reported by Jens Nachtigall on 2011-11-01
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Medium
RJ Skerry-Ryan

Bug Description

This is with mixxx 1.10 branch: Highlight a 10 tracks or so (of a Crate), then right-click "Reload Track Metadata" in the context menu. Sometimes a few of these tracks will then have a dbm of "-1" instead of 0. This is very annoying because with "-1" bpm the autoanalysation is not working and one has to put them back to "0" by hand again in order to start recalculation of bpm.

Sometimes not even the selected tracks are switched to "-1" bpm but some that are further up in the column. Very strange.

Also: I don not know if that relates, but if I change the bpm back to "0" from "-1", another track up the list changes from 0 to "-1".

Sorry, I do not have time to look into it myself...

Related branches

RJ Skerry-Ryan (rryan) wrote :

Thanks for the report. What happens if you click "reload track metadata" again on a track that got a -1?

Changed in mixxx:
milestone: none → 1.10.0
importance: Undecided → Medium
RJ Skerry-Ryan (rryan) wrote :

To prevent the annoying case of -1 blocking BPM detection, I'm changing AnalyserBpm to detect BPM for values of <= 0. We should still get to the bottom of this though.

Am 01.11.2011 15:06, schrieb RJ Ryan:
> Thanks for the report. What happens if you click "reload track metadata"
> again on a track that got a -1?

It goes to 0, but then one of the neighboring tracks (that one above or
below in the crate) goes sometimes to -1.

RJ Skerry-Ryan (rryan) on 2011-11-02
Changed in mixxx:
assignee: nobody → RJ Ryan (rryan)
RJ Skerry-Ryan (rryan) on 2011-11-02
Changed in mixxx:
status: New → Fix Committed
RJ Skerry-Ryan (rryan) wrote :

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.

RJ Skerry-Ryan (rryan) on 2011-12-25
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers