Mixxx

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

Bug #884696 reported by Jens Nachtigall
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Medium
RJ Skerry-Ryan
Mixxx 1.10.0

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

lp://staging/mixxx/1.10
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
Jens Nachtigall (nachtigall) wrote : Re: [Bug 884696] Re: rightclick on "Reload Track Metadata" gives bpm of "-1" sometimes

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)
Changed in mixxx:
assignee: nobody → RJ Ryan (rryan)
RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: New → Fix Committed
Revision history for this message
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)
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6064

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.