Regression: Mixxx 2.6 reanalyzes tracks on every load

[fwcd]

Bug Description

See the associated Zulip thread: https://mixxx.zulipchat.com/#narrow/channel/109122-general/topic/Mixxx.20reanalyzes.20tracks.20every.20time

Mixxx 2.6 seems to reanalyze tracks every time they are loaded to a deck instead of using the cached data:

Screen.Recording.2024-12-30.at.23.29.02.mov

According to a bisect 7a3c515 was the last good, 9b31059 the first bad one (diff), so the issue was very likely introduced here:

• Add stem controls #13086

cc @acolombier

Version

2.6 (latest main)

OS

macOS 15.1.1

[acolombier]

I cannot reproduce the issue (Alan Walker's track was not analysed yet)

Screencast.from.31-12-24.15.26.29.webm

Tested with 22b9eec and default CMake setting (STEM=ON). I will give a go with STEM=OFF which could be causing issues

[Swiftb0y]

Which codec were those tracks in? Maybe it only happens with (non-stem) mp4s?

[fwcd]

AAC/m4a, yeah, that would be worth checking

[acolombier]

Unable to reproduce with both STEM flag to ON and OFF using a .m4a with the following ffprobe:

Input #0, mov,mp4,m4a,3gp,3g2,mj2:
  Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 127 kb/s (default)
    Metadata:
      handler_name    : ISO Media file produced by Google Inc.
      vendor_id       : [0][0][0][0]
    Side data:
      replaygain: track gain - -13.320600, track peak - unknown, album gain - unknown, album peak - unknown, 

I'm wondering if it could be related to a setting on your end. Could you please check the value of these following settings?

[Key],ReanalyzeWhenSettingsChange
[Key],stem_strategy
[BPM],ReanalyzeWhenSettingsChange
[BPM],stem_strategy

[m0dB]

It also happens to me. Maybe a macOS specific issue?

[fwcd]

I can confirm that this happens for MP3s too, at least on macOS

[fwcd]

I did a finer-grained bisect and identified a85964c as the commit introducing the regression.

Perhaps this condition fires for some reason and shouldn't:

mixxx/src/analyzer/analyzerwaveform.cpp

Lines 148 to 157 in a85964c

	#ifdef __STEM__
	// If the waveform was generated without stem information, we need to regenerate
	if (!missingWaveform &&
	((!pTrackWaveform.isNull() &&
	pTrackWaveform->hasStem() != bIsStemTrack) ||
	(!pLoadedTrackWaveform.isNull() &&
	pLoadedTrackWaveform->hasStem() != bIsStemTrack))) {
	missingWaveform = true;
	}
	#endif

(I would parenthesize or split up such a long boolean expression by the way, the precedences of equality/logical operators are a bit hard to remember)

[fwcd]

Seems to be the case. This is the state of each track before missingWaveform is set to true:

debug [AnalyzerThread 3 #4] pTrackWaveform.isNull() = true [src/analyzer/analyzerwaveform.cpp:157]
debug [AnalyzerThread 3 #4] isStemTrack = false [src/analyzer/analyzerwaveform.cpp:161]
debug [AnalyzerThread 3 #4] pLoadedTrackWaveform.isNull() = false [src/analyzer/analyzerwaveform.cpp:162]
debug [AnalyzerThread 3 #4] pLoadedTrackWaveform->hasStem() = true [src/analyzer/analyzerwaveform.cpp:164]

Not sure why pTrackform.isNull() and pLoadedTrackWaveform->hasStem() are true, despite this happening for all kinds of (already analyzed) non-stem files.