Crash maybe related conflicting BPM values

[kek001]

2.3beta

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

[Daniel Schürmann (daschuer)]

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.

[ronso0 (ronso0)]

In more recent 2.3 builds there is a shortcut :)

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

[kek001 (kek001)]

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]

[kek001 (kek001)]

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.

[kek001 (kek001)]

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 #1]: AnalyzerThread - Dequeued next track 17230
Debug [AnalyzerThread 0 #1]: AnalyzerThread - Analyzing QFileInfo(C:\Music\Electronic\Ufomatka - Off The Beaten Track Of The Universe\1 - Ufomatka - Transition To Hyperspace.mp3)
Debug [AnalyzerThread 0 #1]: SoundSourceMp3 - MP3 frame header | layer: 0 mode: 0 #channels: 1 #samples: 36 bitrate: 0 samplerate: 0 flags: "0x0000"
Debug [AnalyzerThread 0 #1]: AnalysisDAO fetched 2 analyses, 3848870 bytes for track 17230 in 25 ms
Debug [AnalyzerThread 0 #1]: Reading waveform from byte array: allSignalSize 437208 visualSampleRate 441 audioVisualRatio 100
Debug [AnalyzerThread 0 #1]: Reading waveform from byte array: allSignalSize 3842 visualSampleRate 3.87331 audioVisualRatio 11385.6
Debug [AnalyzerThread 0 #1]: AnalyzerWaveform - loadStored - Stored waveform loaded
Debug [AnalyzerThread 0 #1]: Skipping AnalyzerEbur128
Debug [AnalyzerThread 0 #1]: AnalyzerBeats preference settings:
Plugin: "qm-tempotracker:0"
Fixed tempo assumption: true
Re-analyze when settings change: false
Fast analysis: false
Debug [AnalyzerThread 0 #1]: Beat calculation skips analyzing because the track has a BPM comput...

[Uwe Klotz (uklotzde-deactivatedaccount)]

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

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

[kek001 (kek001)]

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.

[kek001 (kek001)]

This is not anymore preview problem.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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.

[Be (be.ing)]

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

[kek001 (kek001)]

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.

[Be (be.ing)]

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.

[kek001 (kek001)]

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.

[kek001 (kek001)]

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.

[kek001 (kek001)]

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

[Be (be.ing)]

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

[Be (be.ing)]

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

[Uwe Klotz (uklotzde-deactivatedaccount)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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.

[kek001 (kek001)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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

[Jan Holthuis (holthuis-jan)]

@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

[Uwe Klotz (uklotzde-deactivatedaccount)]

- 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

[Uwe Klotz (uklotzde-deactivatedaccount)]

This DEBUG_ASSERT has not been modified since 5 years.

[Daniel Schürmann (daschuer)]

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

[kek001 (kek001)]

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.

[kek001 (kek001)]

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.

[kek001 (kek001)]

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

[kek001 (kek001)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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.

[kek001 (kek001)]

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.

[kek001 (kek001)]

@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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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

[Jan Holthuis (holthuis-jan)]

@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

[Jan Holthuis (holthuis-jan)]

*Please test

[kek001 (kek001)]

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.

[kek001 (kek001)]

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.

[Swiftb0y (swiftb0y)]

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