Regression: Library (re-)scanning crashes on Win (clean main) -> x64debug reports 'out of memory'

[Eve00000]

Bug Description

Mixxx 2.7.0-alpha-345-g993a9724b4 (up-to-date 20260806)

Happens both on Win 10 & Win 11:

• when starting with clean settings
• adding 1st dir on startup ... possible crash depending on size of the foilder else -> restart -> rescan library (depending on size of the folder)
• adding extra folders to library ... possible crash depending on size of the folder
• happens when rescan library on startup

crash while scanning / importing ...

mixxx.log

20260806-debug.txt

-> The error is due to line 207 in track.cpp
beatsAndBpmModified = trySetBpmWhileLocked(importedBpm);

-> trySetBpmWhileLocked
auto pBeats = mixxx::Beats::fromConstTempo(getSampleRate(),
cuePosition,
bpm);

-> fromConstTempo
VERIFY_OR_DEBUG_ASSERT(sampleRate.isValid() &&
lastMarkerPosition.isValid() && lastMarkerBpm.isValid()) {

Version

Mixxx 2.7.0-alpha-345-g993a9724b4

OS

Win 10 & 11

[ronso0]

Does it only happen in Windows builds?
Does it only happen only with main?

The recent changes in Beats (main) are these https://github.com/mixxxdj/mixxx/commits/main/src/track/beats.cpp

If you find a version that doesn't crash you may either try to do git bisect, or revert the Beats commits one by one (in reverse order obviously, ignore the merge commits).
Enabling the DEBUG_ASSERTIONS_FATAL flag, just in case it's off.

[Eve00000]

It does not happen on Linux (windows compiler is less tolerant for assets):

The cause:
If a stemcontainer has a bpm value in its metadata -> importer / scanner crashes. (When removing the BPM value it passes), so if the folder contains a stemcontainer with BPM ....
this happens when

• adding the file directly
• adding the folder as a library folder -> scan
• adding the file to a folder that's already a library folder -> rescan

!! only when a BPM value is in a stemcontainer, no problem when there's a BPM value in metadata of other tyoe of tracks:

I've been looking at the recent commits to beats, trackdao , scanner... but I can't find it ... maybe this rings a bell...

When importing stems with BPM value in metadata In linux I 'just' get:
critical [LibraryScanner 1] DEBUG ASSERT: "sampleRate.isValid() && lastMarkerPosition.isValid() && lastMarkerBpm.isValid()" in function static mixxx::BeatsPointer mixxx::Beats::fromConstTempo(mixxx::audio::SampleRate, mixxx::audio::FramePos, mixxx::Bpm, const QString&) at ./src/track/beats.cpp:167

[ronso0]

When importing stems with BPM value in metadata In linux I 'just' get:
critical [LibraryScanner 1] DEBUG ASSERT: "sampleRate.isValid() && lastMarkerPosition.isValid() && lastMarkerBpm.isValid()" in function static mixxx::BeatsPointer mixxx::Beats::fromConstTempo(mixxx::audio::SampleRate, mixxx::audio::FramePos, mixxx::Bpm, const QString&) at ./src/track/beats.cpp:167

Okay, nice you found the issue.
You can narrow it down by splitting the DEBUG_ASSERT into one for each prop (sampleRate, lastMarkerPosition,lastMarkerBpm).
Not sure where the BPM is extracted from the stem container. @acolombier any idea where to look?

[Eve00000]

You can narrow it down by splitting the DEBUG_ASSERT into one for each prop (sampleRate, lastMarkerPosition,lastMarkerBpm).

Oh really :-)

The samplerate in types gives an error for sometime:
critical [Main] DEBUG ASSERT: "sampleRate.toDouble() == value" in function static mixxx::audio::SampleRate mixxx::audio::SampleRate::fromDouble(double) at ./src/audio/types.h:186

[ronso0]

Hmm.. Can you provide a short DRM-free Stem file to reproduce the bug?

[Eve00000]

you could use the NI stempack or ...

[ronso0]

I can repro the DEBUG_ASSERT with 2.6 and
SoundSourceProvider "STEM with FFmpeg 4.2.7-0ubuntu0.1"

• import it into Mixxx, let it analyze BPM
• then export to file tags
• hide, then purge
• import again -> DEBUG_ASSERT

BPM are valid, it's the samplerate that's considered invalid.

[daschuer]

I had this with one of my experimental branches lately. It was an MP3 track and the sampleRate was zero in that assertion. The other day the issue was gone.

[ronso0]

I can reproduce reliably with this Stem file.
Is the samplerate just not set yet in the Stem case when it tries to import metadata?

Will try again with mp3 and Flac.