Mixxx crashes on first time jog wheel touch + movement after fresh start of macOS
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Expired
|
Critical
|
Unassigned | ||
2.1 |
Expired
|
Critical
|
Unassigned | ||
2.2 |
Expired
|
Critical
|
Unassigned |
Bug Description
I get sporadic segmentation fault crashes during normal playback of one deck at my gigs. The second deck has a loaded but stopped track in it.
The crash can happen after 1 hour of playing or after 4 hours. I could't figure out any special step to reproduce the crash yet and normally it happens only after a long time of playing. That's why I don't have any backtrace data yet. The last time the crash happened, it happened twice within a short time period as the Auto-DJ was active.
Mixxx: 2.1.0-beta1 (build 2.1 r6501)
OS: Apple macOS High Sierra 10.13.3 (17D47)
CPU: 1,6 GHz Intel Core i5
Video: Intel HD Graphics 6000 1536 MB
Sound: Apple Core driver -> Pioneer DDJ-SX
Another problem I have (and I don't know if it's the origin) is that such segmentation fault crashes also occur after a fresh start of macOS and a fresh start of Mixxx during the first touch and movement of a deck's jog wheel (scratch). I'm using the Pioneer DDJ-SX, the Hercules DJ Console RMX4 or the Hercules DJ Console 4-MX. But this occurs only on this macOS. I have an older MacBook with macOS 10.12 (I think) where the first touch doesn't allow any scratching. It only holds the track. On the second touch I can scratch.
I attached the macOS error report after crashing as the Auto-DJ was active.
Max Beiersdorfer (max-beiersdorfer) wrote : | #1 |
Uwe Klotz (uklotzde-deactivatedaccount) wrote : | #2 |
Now that the fix for lp:1744550 is merged, please test the current version again.
Uwe Klotz (uklotzde-deactivatedaccount) wrote : | #4 |
The second issue seems to be unrelated to the fix, but the crashes during regular usage should be fixed. I just noticed that I pasted the wrong URL and referenced this same bug report ;)
We should change the title to match the second issue and keep this bug report open until the remaining issues are fixed.
Max Beiersdorfer (max-beiersdorfer) wrote : | #5 |
Thank you for the information! I renamed the title according the second issue. I hope I can find time on the weekend to focus on that issue and get some backtrace data.
summary: |
- Sporadic crashes during normal playback + Mixxx crashes on first time jog wheel touch + movement after fresh start + of macOS |
Max Beiersdorfer (max-beiersdorfer) wrote : | #6 |
I was able to reproduce the crash!
Conditions:
- Fresh macOS start
- Connected midi controller
- Mixxx is started with internal sound card configured as sound output in the settings
Actions after starting Mixxx:
- Before doing anything else, I change the sound output in the settings to my external controller sound card
- Apply the changes and close the settings window
- Load a song to Deck 1
- Start playback of Deck 1 (by pressing play on the skin or on my controller)
- During playback I touch/press the jog wheel on my controller for the first time and try to move it.
Results (2 behaviors):
1. Playback is stopped as long as I touch the jog wheel but as I move the jog wheel nothing will happen (expected behavior is scratching). On releasing and touching the jog wheel again I am able to scratch.
2. Playback is stopped and Mixxx crashes!
I was able to create back-traces for the crash:
Last login: Sun Mar 11 13:11:01 on console
Maximilians-Air:~ DJMaxergy$ lldb /Applications/
(lldb) target create "/Applications/
Current executable set to '/Applications/
(lldb) run
Process 558 launched: '/Applications/
2018-03-11 13:14:16.
Call location:
2018-03-11 13:14:16.
2018-03-11 13:14:16.
2018-03-11 13:14:16.
2018-03-11 13:14:16.
2018-03-11 13:14:16.
2018-03-11 13:14:16.
2018-03-11 13:14:16.
Warning [Main]: Configuration file is at version "2.1.0-alpha-pre" instead of the current 2.1.0-beta1
Warning [Main]: QFileInfo:
Warning [Main]: ControlDoublePr
Warning [Main]: ControlDoublePr
Warning [Main]: ControlDoublePr
Warning [Main]: ControlDoublePr
Warning [Main]...
Max Beiersdorfer (max-beiersdorfer) wrote : | #7 |
- MixxxCrash_Back-Trace_03-11-18.rtf Edit (80.5 KiB, application/rtf)
Add: In this case I used the following midi controller: Hercules DJ Console RMX 2.
But the crash occurs with my Pioneer DDJ SX and my Hercules DJ Console 4 MX, too.
For easier analysis I attached the back-trace as rtf file.
Max Beiersdorfer (max-beiersdorfer) wrote : | #8 |
- MixxxCrash_AppleReport_03-11-18.rtf Edit (131.9 KiB, application/rtf)
I also attach the Apple crash report which is being generated after the crash.
Max Beiersdorfer (max-beiersdorfer) wrote : | #9 |
I used the latest beta build: 2.1.0-beta1 (build 2.1-r6518) for reproducing the crash.
Changed in mixxx: | |
importance: | Undecided → Critical |
milestone: | none → 2.1.0 |
Be (be.ing) wrote : | #10 |
Can anyone else reproduce this? I have no controllers with jog wheels to test with.
Be (be.ing) wrote : | #11 |
> Results (2 behaviors):
1. Playback is stopped as long as I touch the jog wheel but as I move the jog wheel nothing will happen (expected behavior is scratching). On releasing and touching the jog wheel again I am able to scratch.
2. Playback is stopped and Mixxx crashes!
I am a bit confused by this description. When exactly does it crash? Does it only crash when touching the jog wheel for the first time on some occasions or every time?
In the future, please attach logs and backtraces as plain text files rather than RTF.
Max Beiersdorfer (max-beiersdorfer) wrote : | #12 |
Ok, a more detailed description:
Crashing case:
Conditions:
- Fresh macOS start
- Connected midi controller
- Mixxx is started with internal sound card configured as sound output in the settings
Actions after starting Mixxx:
- Before doing anything else, I change the sound output in the settings to my external controller sound card
- Apply the changes and close the settings window
- Load a song to Deck 1
- Start playback of Deck 1 (by pressing play on the skin or on my controller)
- During playback I touch/press the jog wheel on my controller for the first time and try to move it.
Result:
Mixxx crashes as soon as I try to move the jog wheel (jog wheel is still pressed to use the scratch function).
If Mixxx has crashed and I restart Mixxx without restarting my MacBook, the result during the first jog wheel touch including movement can be another crash or the playback just stops during jog wheel movement. As soon as I release the jog wheel and press and move it again...the scratch function works as expected.
I could reproduce this behavior on two different MacBooks and three different midi controllers.
I just could figure out any structure of what happens after the first crash and restart of Mixxx (crashing or just stopping playback during first scratch).
Daniel Schürmann (daschuer) wrote : | #13 |
Does it also happy if you try to scratch waveforms by mouse?
Can you watch the memory that is consumed by Mixxx?
Does anyone know why we have no debug symbols included in the Mac version?
I could not reproduce the crash using 2.1.0-beta1 (build 2.1 r6543), macOS 10.13.3 , Vestax VCI-300
CoreAudio 44100Hz @11.6ms
Output= VCI 300
Input=None
Followed step by step as outlined in #12.
@max
* Have you any other inputs/outputs active in Preferences > Sound hardware ?
* Have you multiple controllers connected, and active within Mixxx ?
* Have you customized your controller scripts, or loaded the stock scripts from Preferences > Controllers?
If you launch Mixxx from the terminal
``
/Applications/
``
and make it crash again, can you post the output from the terminal...
Max Beiersdorfer (max-beiersdorfer) wrote : | #15 |
@Daniel:
By trying to scratch waveforms by mouse it doesn't crash. Just the expected behavior.
The memory consumed by Mixxx is about 630 MB to 750 MB just before the crash.
@jus:
My sound configuration at Mixxx startup is:
CoreAudio 44100Hz @9.00227ms (Audio buffer setting 2.9ms)
Only Master = Build-In output Channel 1-2
Then before playing any song, I go to the settings after Mixxx startup and change the sound configuration to:
CoreAudio 44100Hz @4.96559ms (Audio buffer setting 2.9ms)
Master = DJConsole Rmx2 Channel 1-2
Headphones = DJConsole Rmx2 Channel 3-4
This configuration is equal to my other DJ/Midi Controllers (Hercules DJ Console 4-MX, Pioneer DDJ-SX).
Then I load a song to Deck 1, press play and try to touch and move the jog wheel. As soon as I move the jog wheel Mixxx crashes.
I have just one controller connected at a time.
The crash happens with the stock controller scripts and my customized scripts.
If I launch Mixxx from the terminal using "/Applications/
Max Beiersdorfer (max-beiersdorfer) wrote : | #16 |
- soundconfig.xml Edit (369 bytes, application/xml)
This is my sound config file just before the crash
Be (be.ing) wrote : | #17 |
Are you able to compile Mixxx yourself using the optimize=off option with scons to get a backtrace with debugging symbols?
https:/
Daniel Schürmann (daschuer) wrote : | #18 |
Don't use optimize=off Mixx will be unusable slow. The optimize flag does not set or remove the debug symbols.
It could be the debug flag. But I can remember that we have decided to always pack the symbols with Mixxx. Isn't this the case fro Mac?
Max Beiersdorfer (max-beiersdorfer) wrote : | #19 |
I'm sorry @Be but I am still not able to compile Mixxx myself as described here: https:/
It would be great if I could get the compile process running at some point. Under Fedora it's working as described.
Be (be.ing) wrote : | #20 |
Using optimize=native removes the debugging symbols for me with GCC on GNU/Linux. I have to use optimize=off for backtraces to be helpful. I do not notice any appreciable difference in speed between optimize=off and optimize=native.
@max
Reading the forum thread #19, i understand that you try to compile by using QT5, and it failed.
The following steps should allow you to compile the mixx source with qt4. This works for me since ages, currently with macOS 10.13.3. Qt4 is the mixxx default, qt5 support still experimental.
* Install qt4
-----------
brew tap cartr/qt4
brew tap-pin cartr/qt4
brew install qt@4
* Delete scons cache (from mixxx build dir root)
-----
scons --clean
manually remove the following files
.sconsign.dblite
.sconsign.tmp
.sconf_temp
config.log
* build (from the mixx build dir root)
-----
scons stdlib=libc++
This should invoke a build with the following flags:
asan=0 battery=0 buildtime=1 bulk=0 color=0 coreaudio=1 faad=0 ffmpeg=0 hid=1
hss1394=1 ipod=0 localecompare=0 macappstore=0 mad=0 mediafoundation=0 modplug=0
opengles=0 optimize=portable opus=0 perftools=0 perftools_
qdebug=1 qt_sqlite_plugin=0 qtkeychain=0 shoutcast=1 test=False tsan=0 ubsan=0
vamp=1 verbose=1 vinylcontrol=1 wv=0
* launch mixxx from build dir
-----
./mixxx --controllerDebug --resourcePath res
or
./mixxx --developer --controllerDebug --resourcePath res
or just
./mixxx --resourcePath res
There is no need to build a bundle (``scons bundle``) after building from source,
when testing local.
Hopefully this will allow you to build from source, reproduce the bug, and provide another backtrace to pin this down.
Daniel Schürmann (daschuer) wrote : | #22 |
The symbols are included with the -g compiler switch
with optimize=native I get
-c -pipe -Wall -Wextra -g -O3 -ffast-math -funroll-loops -fomit-
with optimize=off I get
-c -pipe -Wall -Wextra -g -pthread -Dx86_64 -DMIXXX_BUILD_DEBUG -D__LINUX__ -D__UNIX__
Both version have the -g
I have found stripcode for MacOs though which removed the debug info:
https:/
I do not know how it works.
Daniel Schürmann (daschuer) wrote : | #23 |
Since we have no progress here, I move it from the 2.1 Milestone scheduled tomorrow.
A fix can go to a point release.
Changed in mixxx: | |
milestone: | 2.1.0 → 2.2.0 |
Be (be.ing) wrote : | #24 |
Max, are you able to compile with Qt4 using jus' instructions above?
Be (be.ing) wrote : | #25 |
This is a very serious bug. I am not comfortable releasing 2.1 until we at least get a good backtrace for this.
Changed in mixxx: | |
milestone: | 2.2.0 → 2.1.0 |
Max Beiersdorfer (max-beiersdorfer) wrote : | #26 |
First of all: under Windows I could not reproduce the crash using the same midi controllers.
I tried to compile Mixxx with the instructions by jus...but failed again:
Maximilians-
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> New Formulae
amber libdill
arm-linux-
ask-cli libomp
auditbeat libsbol
augustus libserialport
autopep8 libtomcrypt
ballerina llvm@5
bamtools lm4tools
bareos-client lmod
bcal lzfse
bcftools mafft
bedops mariadb-
bioawk maxwell
blast mdcat
boost-python3 mill
bwa mint
caffe mmseqs2
calicoctl monero
chrome-export mpir
clblast neomutt
console_bridge nyx
container-diff ocrmypdf
coreos-ct octomap
cp2k odpi
darksky-weather opencascade
dartsim openimageio
dashing orocos-kdl
defaultbrowser parallelstl
diamond php-cs-fixer
docker-squash plank
draco posh
dynare primer3
elektra python@2
fastme qsoas
fcl qtkeychain
field3d restview
flintrock rtptools
fruit samtools
fselect scrcpy
futhark seqtk
ghc@8.2 shelltestrunner
git-sizer shogun
glances sickle
go-bindata siril
go-statik skaffold
go@1.9 skafos
gocryptfs spades
goto sratoolkit
gox srt
gpredict stellar-core
grv stress-ng
gtksourceview@4 telnetd
hlint terraforming
hmmer tj
howdoi tmux-xpanes
hss tnftp
icemon tnftpd
jdupes tomcat@8
jthread...
Max Beiersdorfer (max-beiersdorfer) wrote : | #27 |
OK, I came a bit further, but still reached an error during build process:
[CXX] src/sources/
[CXX] src/sources/
[CXX] src/sources/
In file included from src/sources/
In file included from src/sources/
/usr/local/
found with <angled> include; use "quotes" instead
# include <opus_multistre
1 error generated.
scons: *** [osx64_
scons: building terminated because of errors.
Daniel Schürmann (daschuer) wrote : | #28 |
That is what I have found on the web:
You can either edit the file as proposed or set the Xcode build setting "Always Search User Paths" to YES.
Max Beiersdorfer (max-beiersdorfer) wrote : | #29 |
As far as I've seen this setting is only available inside a Xcode project file which I don't have (I think?). I didn't find this setting in the Xcode preferences itself.
Changed in mixxx: | |
milestone: | 2.1.0 → none |
Be (be.ing) wrote : | #30 |
We have changed the build system to keep debugging symbols in the macOS builds. Max, can you try to reproduce this with the latest build from http://
Be (be.ing) wrote : | #31 |
Now that I have access to a Mac, I tried hacking the Xone K2 mapping to map one of the encoders like a jog wheel with engine.
RJ Skerry-Ryan (rryan) wrote : | #32 |
> # include <opus_multistre
> ^~~~~~~
> "opus_multistre
@Max, that's an unfortunate, known bug in the Homebrew opus package. See the workaround in the Step 4 of the compilation instructions:
https:/
Basically define:
export CFLAGS=
export CXXFLAGS=
before running scons.
Max Beiersdorfer (max-beiersdorfer) wrote : | #33 |
Sorry for the late answer, I was on Easter holidays.
@RJ Ryan: I already considered the workaround after my last post here and got another error (last state before giving it up):
Maximilians-
Maximilians-
Maximilians-
Maximilians-
Maximilians-
scons: Reading SConscript files ...
INFO:root:Target Platform: osx
INFO:root:Target Machine: x86_64
INFO:root:Build: debug
INFO:root:
INFO:root:
INFO:root:Qt path: /usr/local/
Automatically detecting Mac OS X SDK.
XCode developer directory:
Found OS X SDK:macosx10.13
Automatically selected OS X SDK:/Applicatio
Checking whether the C++ compiler works... (cached) yes
Configuring MixxxCore
Configuring SoundTouch
Configuring ReplayGain
Configuring Ebur128Mit
Checking for C library ebur128... (cached) no
Checking for C library libebur128... (cached) no
Checking for C header file sys/queue.h... (cached) yes
Configuring PortAudio
Checking for C library portaudio... (cached) yes
Configuring PortMIDI
Checking for C library porttime... (cached) no
Checking for C library libporttime... (cached) no
Checking for C header file porttime.h... (cached) yes
Checking for C library portmidi... (cached) yes
Checking for C header file portmidi.h... (cached) yes
Configuring Qt
Configuring TestHeaders
Configuring FidLib
Configuring SndFile
Checking for C library sndfile... (cached) yes
Checking whether SFC_SET_
Configuring FLAC
Checking for C header file FLAC/stream_
Checking for C library libFLAC... (cached) yes
Configuring OggVorbis
Checking for C library libvorbisfile... (cached) yes
Checking for C library libvorbis... (cached) yes
Checking for C library libogg... (cached) yes
Checking for C library libvorbisenc... (cached) yes
Configuring OpenGL
Checking for C library GL... (cached) no
Checking for C library opengl32... (cached) no
Checking for C header file OpenGL/gl.h... (cached) yes
Checking for C library GLU... (cached) no
Checking for C library glu32... (cached) no
Checking for C header file OpenGL/glu.h... (cached) yes
Configuring TagLib
Checking for C library tag... (cached) yes
Configuring ProtoBuf
Checking for C library libprotobuf-lite... (cached) yes
Configuring Chromaprint
Checking for C library chromaprint... (cached) yes
Configuring RubberBand
Checking for C library rubberband... (cached) yes
Configuring SecurityFramework
Configuring CoreServices
Configuring IOKit
Configuring QtScriptByteArray
Configuring Reverb
Configuring FpClassify...
Max Beiersdorfer (max-beiersdorfer) wrote : | #34 |
At the moment I'm only able to reproduce the crash using the latest build if I don't use backtracing.
Using backtracing I get the behavior that Mixxx doesn't do scratching while touching and moving the jog wheel for the first time (after starting Mixxx). This would also be the crash situation when I'm not using backtracing.
On touching and moving the jog wheel for the second time I get the expected behavior (scratching).
How else can I submit you the necessary information to see what's happening here?
What else can I do?
Again the actual procedure to generate the crash:
- Booting up MacOS
- Plugging in the MIDI controller
- Starting the terminal and enter "lldb /Applications/
- After that enter "run"
- Now in Mixxx go to the preferences and change the master sound output to the controller sound card channel 1-2 and headphones sound output to the controller sound card channel 3-4 (setting before is "Build-in sound".
- Apply the settings and close the preferences window.
- Load a track to Deck 1 and press play.
- Touch and move the jog wheel -> Track is just stopped/paused instead of scratching back and forth.
- Release jog wheel -> Track is playing again.
- Touch and move the jog wheel again -> Expected scratching is working.
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1749800] Re: Mixxx crashes on first time jog wheel touch + movement after fresh start of macOS | #36 |
Do you always install Qt via homebrew or have you ever installed it via
Qt's installer packages?
Can you share the contents of /usr/local/bin ?
FWIW, I don't install Homebrew to /usr/local, I install it to
$HOME/.homebrew.
On Mon, Apr 9, 2018 at 12:57 PM, Max Beiersdorfer <
<email address hidden>> wrote:
> Sorry for the late answer, I was on Easter holidays.
>
> @RJ Ryan: I already considered the workaround after my last post here
> and got another error (last state before giving it up):
>
> Maximilians-
> Maximilians-
> CFLAGS=
> -I/usr/
> -I/usr/
> Maximilians-
> CXXFLAGS=
> -I/usr/
> -I/usr/
> Maximilians-
> LDFLAGS=
> Maximilians-
> scons: Reading SConscript files ...
> INFO:root:Target Platform: osx
> INFO:root:Target Machine: x86_64
> INFO:root:Build: debug
> INFO:root:
> INFO:root:
> INFO:root:Qt path: /usr/local/
> Automatically detecting Mac OS X SDK.
> XCode developer directory:
> Found OS X SDK:macosx10.13
> Automatically selected OS X SDK:/Applicatio
> ntents/
> Checking whether the C++ compiler works... (cached) yes
> Configuring MixxxCore
> Configuring SoundTouch
> Configuring ReplayGain
> Configuring Ebur128Mit
> Checking for C library ebur128... (cached) no
> Checking for C library libebur128... (cached) no
> Checking for C header file sys/queue.h... (cached) yes
> Configuring PortAudio
> Checking for C library portaudio... (cached) yes
> Configuring PortMIDI
> Checking for C library porttime... (cached) no
> Checking for C library libporttime... (cached) no
> Checking for C header file porttime.h... (cached) yes
> Checking for C library portmidi... (cached) yes
> Checking for C header file portmidi.h... (cached) yes
> Configuring Qt
> Configuring TestHeaders
> Configuring FidLib
> Configuring SndFile
> Checking for C library sndfile... (cached) yes
> Checking whether SFC_SET_
> Configuring FLAC
> Checking for C header file FLAC/stream_
> Checking for C library libFLAC... (cached) yes
> Configuring OggVorbis
> Checking for C library libvorbisfile... (cached) yes
> Checking for C library libvorbis... (cached) yes
> Checking for C library libogg... (cached) yes
> Checking for C library libvorbisenc... (cached) yes
> Configuring OpenGL
> Checking for C library GL... (cached) no
> Checking for C library opengl32... (cached) no
> Checking for C header file OpenGL/gl.h... (cached) yes
> Checking for C library GLU... (cached) no
> Checking for C library glu32... (cached) no
> Checking for C header file OpenGL/glu.h....
Max Beiersdorfer (max-beiersdorfer) wrote : | #35 |
Add: Procedure is described how I TRIED to generate the crash using backtracing. As said before I'm only able to reproduce the crash without using the terminal and the backtracing and starting Mixxx directly through the app shortcut.
RJ Skerry-Ryan (rryan) wrote : | #37 |
Oh! Your final include path (Building with CXXFLAGS: ...) includes
-I/usr/
I wonder how that got on there? It isn't in your CFLAGS/CXXFLAGS, since
you're setting those manually. Maybe our Qt scons code is setting that
erroneously, but QTDIR is properly detected as /usr/local/
7_3.
On Mon, Apr 9, 2018 at 2:32 PM, RJ Skerry-Ryan <email address hidden> wrote:
> Do you always install Qt via homebrew or have you ever installed it via
> Qt's installer packages?
>
> Can you share the contents of /usr/local/bin ?
>
> FWIW, I don't install Homebrew to /usr/local, I install it to
> $HOME/.homebrew.
>
> On Mon, Apr 9, 2018 at 12:57 PM, Max Beiersdorfer <
> <email address hidden>> wrote:
>
>> Sorry for the late answer, I was on Easter holidays.
>>
>> @RJ Ryan: I already considered the workaround after my last post here
>> and got another error (last state before giving it up):
>>
>> Maximilians-
>> Maximilians-
>> CFLAGS=
>> -I/usr/
>> -I/usr/
>> Maximilians-
>> CXXFLAGS=
>> -I/usr/
>> -I/usr/
>> Maximilians-
>> LDFLAGS=
>> Maximilians-
>> scons: Reading SConscript files ...
>> INFO:root:Target Platform: osx
>> INFO:root:Target Machine: x86_64
>> INFO:root:Build: debug
>> INFO:root:
>> INFO:root:
>> INFO:root:Qt path: /usr/local/
>> Automatically detecting Mac OS X SDK.
>> XCode developer directory:
>> Found OS X SDK:macosx10.13
>> Automatically selected OS X SDK:/Applicatio
>> ntents/
>> Checking whether the C++ compiler works... (cached) yes
>> Configuring MixxxCore
>> Configuring SoundTouch
>> Configuring ReplayGain
>> Configuring Ebur128Mit
>> Checking for C library ebur128... (cached) no
>> Checking for C library libebur128... (cached) no
>> Checking for C header file sys/queue.h... (cached) yes
>> Configuring PortAudio
>> Checking for C library portaudio... (cached) yes
>> Configuring PortMIDI
>> Checking for C library porttime... (cached) no
>> Checking for C library libporttime... (cached) no
>> Checking for C header file porttime.h... (cached) yes
>> Checking for C library portmidi... (cached) yes
>> Checking for C header file portmidi.h... (cached) yes
>> Configuring Qt
>> Configuring TestHeaders
>> Configuring FidLib
>> Configuring SndFile
>> Checking for C library sndfile... (cached) yes
>> Checking whether SFC_SET_
>> Configuring FLAC
>> Checking for C header file FLAC/stream_
>> Checking for C library libFLAC... (cached) yes
>> Configuring OggVorb...
RJ Skerry-Ryan (rryan) wrote : | #38 |
I'd love to get to the bottom of this, I agree it's pretty troubling. It would be great to know the status of this bug in 2.1.x and 2.2.x.
Max, would you be willing to try to reproduce using Mixxx 2.1.4 and Mixxx 2.2.0 beta?
http://
http://
No need to run using a debugger. If you get a crash, please just attach the macOS crash report found in ~/Library/
RJ Skerry-Ryan (rryan) wrote : | #39 |
@Max, thanks so much for your testing so far. If you get the chance, it would be really helpful to see if the above two links (Mixxx 2.1.4 and 2.2.0 beta) crash. The mac crash report that they generate should have a useful backtrace in them, since those builds have debug symbols enabled.
Be (be.ing) wrote : | #40 |
Considering the lack of response and this hasn't been replicated with 2.2, I'm removing the 2.2.0 milestone.
Max Beiersdorfer (max-beiersdorfer) wrote : | #41 |
Sorry for the late response. I finally found time to test it using Mixxx 2.1.4 and Mixxx 2.2.0 beta and tested it several times in different constellations.
I was NOT able to reproduce a crash anymore!
BUT still...after a fresh boot of MacOS, a fresh start of Mixxx and after reconfiguring the sound settings from internal sound to the controller's sound card...I wasn't able to do scratching on touching a jog wheel of a playing deck for the first time. The track only stops/pauses at the touched position. After releasing and touching the jog wheel again I can scratch normally.
It's not that critical anymore but still annoying when you forget to touch the jog wheel once before you want to do some scratching.
Daniel Schürmann (daschuer) wrote : | #42 |
Thank you for cinfiming.
Would you mind to file a new bug for this?
Max Beiersdorfer (max-beiersdorfer) wrote : | #43 |
Ok, I reported a new bug for the scratching problem: http://
Changed in mixxx: | |
status: | New → Incomplete |
Launchpad Janitor (janitor) wrote : | #44 |
[Expired for Mixxx 2.1 because there has been no activity for 60 days.]
Launchpad Janitor (janitor) wrote : | #45 |
[Expired for Mixxx 2.2 because there has been no activity for 60 days.]
Launchpad Janitor (janitor) wrote : | #46 |
[Expired for Mixxx because there has been no activity for 60 days.]
Changed in mixxx: | |
status: | Incomplete → Expired |
Swiftb0y (swiftb0y) wrote : | #47 |
Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https:/
lock status: | Metadata changes locked and limited to project staff |
The crash is most likely caused by a known bug in the 2.1 beta release. Sorry for that, the fix is still pending to be merged: /bugs.launchpad .net/mixxx/ +bug/1749800
https:/