Crash maybe related conflicting BPM values

[mixxxbot]

Reported by: kek001 Date: 2021-03-16T06:05:57Z Status: Fix Released Importance: Critical Launchpad Issue: lp1919278 Tags: windows Attachments: [debug shot](https://bugs.launchpad.net/bugs/1919278/+attachment/5477634/+files/debug shot)

---

2.3beta

Windows 10. After using preview column (icon) for couple song mixxx do a fatal crash.

[mixxxbot]

Commented by: daschuer Date: 2021-03-16T06:45:22Z

---

Please look for a mixxx.log file with a number prefix from your crashing run.
https://github.com/mixxxdj/mixxx/wiki/Finding%20the%20mixxx.log%20file

It likely contains more info about the crash. Copy the tailing lines here.

Can you remember which track was involved in the crash?

If it was a M4A/AAC file, you likely suffer this bug: https://bugs.launchpad.net/mixxx/+bug/1899242 We have recently removed the DEBUG_ASSERT causing a fatal error in our alpha build. In this case installing the current 2.3 beta will fix the crash.

[mixxxbot]

Commented by: ronso0 Date: 2021-03-16T14:01:36Z

---

In more recent 2.3 builds there is a shortcut :)

Preferences > Lbrary > (at the bottom) Open Settings Folder

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T15:06:13Z

---

I am using 8078. Yesterday it was crashing all the time, when i open the mixxx and using preview. it just took minute or two, now i cant reproduce, so i going to play set now, and checking the tracks what i play. The files were mp3.

This the tail of log, begin is just normal start procedure. there is no other info at end, because of fatal crash. Maybe I have bad mp3 file or something ? I give more info later, if i know more.

Debug [Main]: BaseTrackCache(0x1fcdbaa4510) updateIndexWithQuery took 0 ms
Debug [Main]: Successfully deserialized BeatGrid
Debug [Main]: Successfully deserialized KeyMap
Debug [Main]: BaseTrackCache(0x1fcdbaa4510) updateIndexWithQuery took 0 ms
Debug [Main]: BaseTrackPlayerImpl::slotLoadTrack "[PreviewDeck1]"
Debug [CachingReaderWorker 9]: SoundSourceMp3 - MP3 frame header | layer: 0 mode: 0 #channels: 1 #samples: 36 bitrate: 0 samplerate: 0 flags: "0x0000"
Debug [CachingReaderWorker 9]: SoundSourceMp3 - MP3 frame header | layer: 3 mode: 2 #channels: 2 #samples: 36 bitrate: 320000 samplerate: 44100 flags: "0x00c8"
Warning [CachingReaderWorker 9]: SoundSourceMp3 - Recoverable MP3 header decoding error: lost synchronization
Warning [CachingReaderWorker 9]: SoundSourceMp3 - MP3 frame header | layer: 3 mode: 2 #channels: 2 #samples: 36 bitrate: 320000 samplerate: 44100 flags: "0x00c8"
Debug [CachingReaderWorker 9]: SoundSourceMp3 - MP3 frame header | layer: 4 mode: 2 #channels: 2 #samples: 36 bitrate: 320000 samplerate: 44100 flags: "0x5000"
Warning [CachingReaderWorker 9]: SoundSourceMp3 - Recoverable MP3 header decoding error: reserved header layer value
Warning [CachingReaderWorker 9]: SoundSourceMp3 - MP3 frame header | layer: 4 mode: 2 #channels: 2 #samples: 36 bitrate: 320000 samplerate: 44100 flags: "0x5000"
Debug [CachingReaderWorker 9]: SoundSourceMp3 - MP3 frame header | layer: 4 mode: 2 #channels: 2 #samples: 36 bitrate: 320000 samplerate: 44100 flags: "0x4000"
Warning [CachingReaderWorker 9]

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T16:20:01Z

---

Actually now when I am testing this problem. The crash can happend when loading mp3 track. so i dont know is this preview related or not.

Not every track, but its happening, i dont know whats going on. the log has no info.

I tried one track which crashed, doing clean grid and bmp, and wave. then re-analyzed well, and loaded, then when i tried other tracks from same album they didnt crash but started crashing, and the track which i reanalyzed and loaded well started crash again.

Earlier i tried preview my playlist about 80 song they went well, so its pretty confusing. i try to load latest build.

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T16:51:12Z

---

I installed 8083 oke, first run, it crashed, and second run it didnt crash it. Third opening mixxx crashed. and its not leave traces to log. these what i try are different tracks. i will play it more, just playing and not using preview etc... and using. i will retest things without using preview and using it during or trying doing set. i will report tommorow more, or this bug report will be full of nonsense text from me.

last tail of log.

SoundManager::setupDevices()
Debug [Main]: SoundDevicePortAudio::open() "SoundDeviceId(Speakers (Realtek(R) Audio), 3)"
Debug [Main]: framesPerBuffer: 1024
Debug [Main]: Requested sample rate:  44100 Hz, latency: 23.22 ms
Debug [Main]: Output channels: 4 | Input channels: 0
Debug [Main]: Opening stream with id 3
Debug [Main]: Opened PortAudio stream successfully... starting
Debug [Main]: PortAudio: Started stream successfully
Debug [Main]:    Actual sample rate:  44100 Hz, latency: 23.22 ms
Debug [Main]: SoundDeviceNetwork - open: "Network stream"
Debug [Main]: framesPerBuffer: 1024
Debug [Main]: Requested sample rate:  44100 Hz, latency: 23219954 ns
Debug [Main]: Using "Speakers (Realtek(R) Audio)" as output sound device clock reference
Debug [Main]: 2 output sound devices opened
Debug [Main]: 0 input sound devices opened
Debug [Main]: Displaying main window
Debug [Main]: Running Mixxx
Debug [Main]: ControllerManager::getControllerList
Debug []: SSE: Enabling denormals to zero mode
Debug []: SSE: Enabling flush to zero mode
Debug []: Denormals to zero mode is working
Debug [Main]: Successfully deserialized BeatGrid
Debug [Main]: Successfully deserialized KeyMap
Debug [Main]: BaseTrackCache(0x1ff68e89fd0) updateIndexWithQuery took 0 ms
Debug [Main]: BaseTrackPlayerImpl::slotLoadTrack "[Channel1]"
Debug [CachingReaderWorker 1]: SoundSourceMp3 - MP3 frame header | layer: 0 mode: 0 #channels: 1 #samples: 36 bitrate: 0 samplerate: 0 flags: "0x0000"
Debug [Main]: TrackAnalysisScheduler - Resuming
Debug [Main]: AnalyzerThread - Enqueueing next track 17230
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: AnalyzerThread - Dequeued next track 17230
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: AnalyzerThread - Analyzing QFileInfo(C:\Music\Electronic\Ufomatka - Off The Beaten Track Of The Universe\1 - Ufomatka - Transition To Hyperspace.mp3)
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: SoundSourceMp3 - MP3 frame header | layer: 0 mode: 0 #channels: 1 #samples: 36 bitrate: 0 samplerate: 0 flags: "0x0000"
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: AnalysisDAO fetched 2 analyses, 3848870 bytes for track 17230 in 25 ms
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: Reading waveform from byte array: allSignalSize 437208 visualSampleRate 441 audioVisualRatio 100
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: Reading waveform from byte array: allSignalSize 3842 visualSampleRate 3.87331 audioVisualRatio 11385.6
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: AnalyzerWaveform - loadStored - Stored waveform loaded
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: Skipping AnalyzerEbur128
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: AnalyzerBeats preference settings: 
Plugin: "qm-tempotracker:0" 
Fixed tempo assumption: true 
Re-analyze when settings change: false 
Fast analysis: false
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: Beat calculation skips analyzing because the track has a BPM computed by a previous Mixxx version and user preferences indicate we should not change it.
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: Key detection is deactivated
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: AnalyzerThread - Skipping track analysis because no analyzer initialized.
Debug [Main]: BaseTrackCache(0x1ff68e89fd0) updateIndexWithQuery took 0 ms
Debug [Main]: Committing transaction on "MIXXX-1" result: true
Debug [Main]: Successfully deserialized BeatGrid
Debug [Main]: Successfully deserialized KeyMap
Debug [Main]: BaseTrackCache(0x1ff68e89fd0) updateIndexWithQuery took 0 ms
Debug [Main]: BaseTrackPlayerImpl::slotLoadTrack "[PreviewDeck1]"
Debug [CachingReaderWorker 9]: SoundSourceMp3 - MP3 frame header | layer: 0 mode: 0 #channels: 1 #samples: 36 bitrate: 0 samplerate: 0 flags: "0x0000"
Debug [CachingReaderWorker 9]: TrackMetadata - Modifying duration: 499435102040 ns -> 499408979591 ns
Debug [Main]: BaseTrackCache(0x1ff68e89fd0) updateIndexWithQuery took 0 ms
Debug [Main]: TrackAnalysisScheduler - Resuming
Debug [Main]: AnalyzerThread - Enqueueing next track 17231
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: AnalyzerThread - Dequeued next track 17231

[mixxxbot]

Commented by: uklotzde Date: 2021-03-16T17:16:13Z

---

Without a backtrace we won't be able to analyze your crashes:

https://github.com/mixxxdj/mixxx/wiki/creating_backtraces

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T17:24:07Z

---

Oke I will try to do it, because now its crashing also when try to analyze tracks, not every time sometimes its analyze a track well and when trying to again it wont. It do also for tracks which has analyzed well few weeks back.

This is so wierd. I will try to go an older version what i know was working and then try to do that backtrace.

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T17:32:54Z

---

This is not anymore preview problem.

[mixxxbot]

Commented by: uklotzde Date: 2021-03-16T17:37:00Z

---

Since no one else reported any issues and the crashes seem to appear randomly this is probably an issue with your system (hardware, OS, graphics driver) and not Mixxx in particular.

[mixxxbot]

Commented by: Be-ing Date: 2021-03-16T17:49:55Z

---

It's plausible it's a problem with kek001's computer rather than Mixxx, but we don't have enough information yet to know.

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T18:15:42Z

---

I just made a observation, it may a conflict with BPM.

Because all my "old" tracks plays well, but i have problem with tracks i have analyzed after updating 8043 build.

I could fix crashing tracks, the column where is BPM (C_BPM) its not same what is in the DECK BPM (D_BPM).

Like one track C_BPM was 115 also when I clicked it. but the D_BPM was something like 114.97. But when i change it the value of D_BMP, it didnt crash anymore.

The track name is Kindom Within. and there is other one too. https://ektoplazm.com/free-music/trd-lucid-dreaming

I saw also other situation a tracks where C_BPM value after click it, was different than D_BPM and when i change value of C_BMP it didnt crash.

THis is what i think now but it may change while I study this more. Conflict values of BPM. or something which is related it.

[mixxxbot]

Commented by: Be-ing Date: 2021-03-16T18:27:13Z

---

Thank you, that is helpful information. Considering this appears to be a regression from a recent change, I think we should take care of it before releasing 2.3.0.

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T18:40:59Z

---

No problem, I will be very happy when could start using mixxx 2.3 full speed. I like it 2.3 muchos, some new features makes my life much more easier, and logical. Thank you people who put huge effort and time and commitment for this nice application.

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T18:54:46Z

---

I see often these when there are decimal numbers in BPM. like i click track where was decimals, it loaded well, but when try to load next track it crash or sometimes immediately. Still using build 8083, and now i know how to deal the situation, i can avoid the crash, or not use a track.

First i was thinking there could be a problem with mp3 and used mp3 diags application.

This crash can happend during loading a track to deck, or sending them for analyze or just click the BMP value on deck, or using preview. Maybe samplers too, havent test it.

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T18:56:55Z

---

mistake: "Just click the BMP value on deck"----> i meant BPM column

[mixxxbot]

Commented by: Be-ing Date: 2021-03-16T19:16:30Z

---

This seems to be a problem with BeatGrid rather than decoding the audio.

[mixxxbot]

Commented by: Be-ing Date: 2021-03-16T19:38:48Z

---

Any of these recent PRs may have caused this: https://github.com/mixxxdj/mixxx/pull/3694 https://github.com/mixxxdj/mixxx/pull/3700 https://github.com/mixxxdj/mixxx/pull/3626 https://github.com/mixxxdj/mixxx/pull/3666 https://github.com/mixxxdj/mixxx/pull/3668

[mixxxbot]

Commented by: uklotzde Date: 2021-03-16T20:20:54Z

---

I remember that I explicitly tested resetting and re-analyzing the BPM of MP3 files that only store an integer number in file tags.

We need to find out the exact steps that cause such a crash.

[mixxxbot]

Commented by: uklotzde Date: 2021-03-16T21:17:36Z

---

I am not able to trigger a crash when messing around with BPM values. Even not if reanalyzing, playing, and previewing the same track at once.

[mixxxbot]

Commented by: kek001 Date: 2021-03-16T22:28:49Z

---

Windows 10, The track what i wrote above, shows deck area 114.96, library column it shows 115

the value after click and reanalyze shows 114.96xxxxx if i dont enter 115, it will crash while loading

Kindom within track which is mp3 and same kind of thing happening some other tracks too. Mixxx not crash if i try to load tracks which has decimals and i had analyze them sometime ago. before 8043. And they will crash if I do clear BMP,GRID,WAVE and reanalyze. I have tested, and not want do lot of them, dont know how long sqlite database will tolarate huge ammount of crashes.

[mixxxbot]

Commented by: uklotzde Date: 2021-03-16T22:47:13Z

---

SQLite is a cockroach ;) I have suffered a lot of crashes and none did any harm to my database. I am always using my main database for development.

[mixxxbot]

Commented by: uklotzde Date: 2021-03-16T22:48:37Z

---

All the tracks from the release have integer bpms when analyzed with the latest version. But even if I tap or edit the bpm and then re-analyze nothing weird happens.

[mixxxbot]

Commented by: uklotzde Date: 2021-03-16T22:50:11Z

---

We need Windows backtraces in case this issue only affects Windows.

[mixxxbot]

Commented by: Holzhaus Date: 2021-03-16T22:53:29Z

---

@kek001 did you untick "Assume constant tempo" in the beat detection preferences?

If you are worried about your database, you can just back up your mixxx user directory: https://manual.mixxx.org/2.3/en/chapters/getting_started.html#upgrading-mixxx

[mixxxbot]

Commented by: uklotzde Date: 2021-03-16T23:10:57Z

---

• Disable "Assume constant tempo"
• Tap the bpm

-> critical [Main] DEBUG ASSERT: "!"BeatMap::setBpm() not implemented"" in function virtual mixxx::BeatsPointer mixxx::BeatMap::setBpm(double) at ../src/track/beatmap.cpp:636

[mixxxbot]

Commented by: uklotzde Date: 2021-03-16T23:12:22Z

---

This DEBUG_ASSERT has not been modified since 5 years.

[mixxxbot]

Commented by: daschuer Date: 2021-03-17T01:06:34Z

---

I have experienced this legacy issue as well during development, and fixed it. Is must have sneaked back in.

At least the fix is still there: https://github.com/mixxxdj/mixxx/blob/bca86b109f9244dbcdc8ab16b16fdb3a799807eb/src/track/track.cpp#L274

[mixxxbot]

Commented by: kek001 Date: 2021-03-17T04:57:19Z

---

I do backups, i was more worried if sqlite database slowly degenerates and my backups will carry those untill it blows. Good to know it is hard as rockroach. I still have constant BMP on. I will do backtrace.

[mixxxbot]

Commented by: kek001 Date: 2021-03-17T16:34:36Z

---

Update:

I was thinking will clean mixxx folders and uninstall before doing backtrace, if problem still exist.

I cleaned using revo uninstaller. and then installed latest build 8086, i noticed uninstalling left lame dll's. i removed those manually.

I was thinking i can have whatever kind of dll etc because installing so manyt times new builds. Better do fresh start.

I dont know is it a new 8086 build or fresh set of dll's etc. Now when testing 30 mins i can't crash the Mixxx.

Sorry if i have waisted your valuable time.

It looks can close this, i will stress test mixxx if i can crash it, so far looks good.

[mixxxbot]

Commented by: kek001 Date: 2021-03-17T17:12:13Z

---

dang crash. and seconds crash.so going to backtrace route

[mixxxbot]

Commented by: kek001 Date: 2021-03-17T19:17:06Z Attachments: [debug shot](https://bugs.launchpad.net/mixxx/+bug/1919278/+attachment/5477634/+files/debug shot)

---

i tried run x64dbg. What you need for me do, last time when i have used debugger early 90's so i cant remember nothing. I need help for using it.

please look attachment of screenshot.

[mixxxbot]

Commented by: uklotzde Date: 2021-03-17T19:47:26Z

---

Ok, looks like another debug assertion triggered that reveals an inconsistency between the beat grid and the nominal value stored as metadata. This should happen on any platform, not only Windows.

We need to know how you use and how you are able to get there. It might also depend on your settings, namely Library and Beat Detection.

[mixxxbot]

Commented by: kek001 Date: 2021-03-17T19:55:32Z

---

this is moment when mixxx crash, i loaded decimal track thats it. showing text loading track. after this mixxx just disapear if i try to press run from debugger it will just print same info to log area.

[mixxxbot]

Commented by: kek001 Date: 2021-03-18T05:00:42Z

---

@Uwe Klotz

"It might also depend on your settings, namely Library and Beat Detection."

WHat you mean ?, there are not lot things what i can set in preferences, directory path is very simple short and latin characters. I am using a settingspaths startup option.

But now for debugging i copy configs etc.. to default mixxx folder. I have tested sqlite file integrity using db browser and earlier i tested using sqlite expert.

BPM enabled, queen mary, assume constant beat.

[mixxxbot]

Commented by: uklotzde Date: 2021-03-18T12:36:44Z

---

https://github.com/mixxxdj/mixxx/pull/3722

[mixxxbot]

Commented by: Holzhaus Date: 2021-03-18T13:15:52Z

---

@kek001 Please the pull request that Uwe linked aboce and check if you can still trigger the crash. Instructions can be found here: https://github.com/mixxxdj/mixxx/wiki/Testing#github-pull-requests

[mixxxbot]

Commented by: Holzhaus Date: 2021-03-18T13:16:07Z

---

*Please test

[mixxxbot]

Commented by: kek001 Date: 2021-03-18T14:07:35Z

---

I tested head 8090, ~70 tracks decimals and then other tracks, included tracks which earlier crashed.

It looks good no crash.

I will try to do a set later. Then I can verify it works, not want say yes and then no again.

[mixxxbot]

Commented by: kek001 Date: 2021-03-18T21:08:34Z

---

Sometimes have to be happy because couldnt do something or achieve. I played set and did all kind of stuff, it works well no crash i think i can verify its working, and this issue is solved.

[mixxxbot]

Issue closed with status Fix Released.