-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 when one deck on hot cue loop and loading to another deck #11257
Comments
I can not confirm with 2.4-alpha-1419 Does it matter which track you load on deck2? Hotcues, no hotcues, cue loops, anything? |
I thought the backtrace procedure would say it all. So it doesn't matter what track I load on any deck. And after checking I agree it is not as simple as "turn cueloop on deck1 and load to deck2". The problem occur with some combination of these steps: on Deck1 put some hotcues, put cueloop and leave it active; on Deck2 turn On the Key Lock, put some hotcues, put cueloop, play, sync, eject and load the ejected track again. The crash still occur if out of these steps above I do not use cueloop. So cueloop not a cause. But it possible will never happen if I dont turn Key Lock on. |
New Backtrace for the updates above |
EXCEPTION_BREAKPOINT mixxx.WLabel::setText+6D mixxx.WTrackProperty::updateLabel+90 This crashing backtrace looks unsuspicious. Such issues are hard to fix remotely. So we need your help. Is the Mixxxx 2.3.3 affected as well? |
So I had to uninstall Mixxx to install 2.3.3. And couldn't crash it with the same pattern. |
That's great. |
You are right. Luckily I have found the installer of this version in the bin. So it is: Do you want me to go through versions on this page to find a suspect one? http://downloads.mixxx.org/snapshots/2.4/ |
Yes, there is a good chance you find the version we can blame. |
Some additional notes. It appears EJECT is also co-offender here. |
Greate, this means we can blame this one: |
@RadioDM Please try out this build: https://github.com/daschuer/mixxx/actions/runs/4181327888 |
I have tested the release above. No more crashes, no matter what I try to make it again. Everything else is working as it should, AFAIC. Seems like a good job. |
Thank you for testing. |
@RadioDM please try this build: https://github.com/daschuer/mixxx/actions/runs/4197090113 |
So the given test build gives crash. Hopefully the other half is not :D |
@RadioDM Please file another issue for that and let us know which builds it occurs with (releases from the Download page, or just PRs build by CI). Thank you! |
@RadioDM Please checkout this build. I have not yet found something obvious, so we need to narrow don possible changes. |
Couldn't reproduce bug on this one. |
And this? https://github.com/daschuer/mixxx/suites/11219267741/artifacts/574162328 |
Couldn't crash this one too |
I was finally able to reproduce and hopefully fix this issue. |
@RadioDM You will find a build for testing at the bottom of this page once the workflow has been finished: https://github.com/mixxxdj/mixxx/actions/runs/4344515264 |
So, there is no that crash we were hunting, but this build gives another glitch meaning that (under conditions explained below) waveform overviews are now not loaded. After a track was already once loaded onto deck during this Mixxx run, anytime I want to load that track again on any (empty!) deck, the waveform overview will not load (with intro, hotcues points visible properly). This will happen always for any track that was previously loaded during this run (no matter if was analysed before or not), but will NOT happen if I load previously played track on the NOT empty deck (I think the same conditions applied for crash/no-crash). Empty waveform on image: Only once instead of empty waveform I had glitched waveform / wrong scaled. The wrong waveform would look the same every time I load it on empty deck, but only for this run of Mixxx. Image (top = glitch, bottom = normal): This are my waveform settings, for sake of reproducing or anything :) |
Thank you for confirming that the crasher is fixed. I can confirm the issue with the waveform overview and it should be fixed with: |
It will appear here as usual: https://github.com/mixxxdj/mixxx/actions/runs/4351344393 |
Yes, with this one there is no crash and no glitch |
Juchhu! Thank you for the good cooperation and your patience with this hard to crack nut. |
@daschuer I still experience the glitch with wrong scaled waveform images. When it happens I must load the track again so the waveform display fine (never got a missing waveform glitch tho). Was it somehow fixed later? I am still on the latest version that has been mentioned here, and on mixx.org download page the alpha seems to be lower number (1425) that the one I got (1435) |
The casher fix has been merge to https://downloads.mixxx.org/snapshots/2.4/mixxx-2.4-alpha-1437-g96c5b4987e-win64.msi The waveform glitch is fixed in mixxx-2.3.4-9-geeae59a9f9.msi We have not yet a 2.5 alpha with the fix. I have just merged it and will appear here: https://github.com/mixxxdj/mixxx/actions/runs/4633381583 once the build is finished. |
Thank you for detailed response. So 2.4-alpha-1467 is the one I want. I just was confused as the mixxx.org website had the alpha version prior to mine. I probably again forgot the latest alpha 2.4 on the mixx.org is not the truly latest. |
Bug Description
When one deck is on an active hotcue loop (loop saved as a hotcue point) and loading track to the other deck, Mixxx crash. It does not crash if track is on normal loop, or in any other instance
It happened on 2.4.0.8748-alpha, and still persist after updated to latest version 2.5.0.8783 alpha
I am attaching the backtrace log
log-śr. lut 8 19-35-27 2023.txt
Version
2.5.0.8783 alpha
OS
Windows 10 Pro 21H2
The text was updated successfully, but these errors were encountered: