Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash maybe related conflicting BPM values #10350

Closed
mixxxbot opened this issue Aug 23, 2022 · 40 comments
Closed

Crash maybe related conflicting BPM values #10350

mixxxbot opened this issue Aug 23, 2022 · 40 comments

Comments

@mixxxbot
Copy link
Collaborator

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 mixxxbot added the bug label Aug 23, 2022
@mixxxbot
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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


This is not anymore preview problem.

@mixxxbot
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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


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

@mixxxbot
Copy link
Collaborator Author

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


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

@mixxxbot
Copy link
Collaborator Author

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


Any of these recent PRs may have caused this:
#3694
#3700
#3626
#3666
#3668

@mixxxbot
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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


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

@mixxxbot
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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


This DEBUG_ASSERT has not been modified since 5 years.

@mixxxbot
Copy link
Collaborator Author

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:

} else if ((m_pBeats->getCapabilities() & mixxx::Beats::BEATSCAP_SETBPM) &&

@mixxxbot
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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


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

@mixxxbot
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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


#3722

@mixxxbot
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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


*Please test

@mixxxbot
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Issue closed with status Fix Released.

@mixxxbot mixxxbot transferred this issue from another repository Aug 24, 2022
@mixxxbot mixxxbot added this to the 2.3.0 milestone Aug 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant