Play control stops responding, stuck on play status

[Esteban Serrano]

Happens on:
mixxx v1.11.0 (x64) build r3863
Ubuntu 12.04

Play control stops responding and track gets stuck on "playing" status, this can happen independently on either deck (1 or 2). I have not found the exact way of reproducing the bug, but seems to happen after setting/deleting hot cues (although not everytime an action is performed on one). The play control stays unresponsive on both GUI and external controller (Denon MC2000). Other controls on the same deck, such as pitch slider, hot cues, loop in/out/exit, EQs, etc. remain responsive. Play control unresponsiveness remains even after loading a different track on the affected deck, and it seems that the only way to regain control is to restart Mixxx.

I have not used Mixxx long enough without the MC2000 controller to say that this bug ocurrs without a controller too. MIDI debug shows normal MIDI messages for all buttons on the controller. This discards that the controller is sending play commands continuously.

Play button for both decks is mapped through XML file only, no controller-specific js method is called on play button down or up. However, engine.connectControl("[Channel"+i+"]", "play", "mc2000.playSetLed"); is called on controller script init, for channels (i) 1 and 2, for setting the LED only. All engine.connectControl calls are made in the init function. The controller scripts can be found here: http://www.mixxx.org/forums/viewtopic.php?f=7&t=6062

This bug makes Mixxx unreliable for performing live.

[Daniel Schürmann (daschuer)]

It would be nice if you could test the latest master. The play button receives a lot of updates so the bug might be fixed without knowing it.
Have you managed to build Mixxx from source or do you need help?

[Esteban Serrano (e.serrano.r)]

I just did what's detailed here: http://mixxx.org/wiki/doku.php/compiling_on_linux , although when running scons, it failed because of some unmet dependencies, which I then installed from apt-get.

When building, I got this message just before it stopped:

In file included from src/engine/bpmcontrol.cpp:11:0:
src/visualplayposition.h:59:35: error: ‘PaStreamCallbackTimeInfo’ does not name a type
src/visualplayposition.h:59:61: error: ISO C++ forbids declaration of ‘timeInfo’ with no type [-fpermissive]
src/visualplayposition.h:71:12: error: ‘PaStreamCallbackTimeInfo’ does not name a type
scons: *** [lin64_build/engine/bpmcontrol.o] Error 1
scons: building terminated because of errors.

[Daniel Schürmann (daschuer)]

You have probably the wrong Portaudio version installed.

Please try again after installing:

sudo apt-get install portaudio19-dev

[Esteban Serrano (e.serrano.r)]

Thanks Daniel, that was the problem, now the compilation completed.

Since I won't be able to test it with my controller for a week (I'm away from home), could you tell me: is it normal that when analysing the library, I got so many warnings of the type:

"TagLib: ID3v2.4 no longer supports the frame type TDAT. It will be discarded from the tag.
TagLib: MPEG::Header::parse() -- Invalid sample rate."

And also why is there no beat/key analyzer is available on the preferences? Since I was using beat detection when the bug happened, I would like beat info to be available here as well (and yes, it also makes testing more fun).

I ran this command to start mixxx (from the dir where I downloaded and compiled the master version, since I don't know what would be overwritten using the defaults):
$ ./mixxx --resourcePath res/ --settingsPath ~/.mixxx-built-from-src

Thanks,

Esteban

[RJ Skerry-Ryan (rryan)]

Hi Esteban -- you hit a bug that I caused in how we detect VAMP plugins for developer setups.

I've fixed this in master: https://github.com/mixxxdj/mixxx/commit/1122e4aebd9b1ee0a3461f57ddbcbdb9741bfcc4

Please pull from git and re-compile -- that should get you a beat and key detector. Sorry for the trouble!

[Bjoern K. (amusing-random-alias)]

This bug also affects me.

OS: Arch Linux
Mixxx Versions: 1.11.0 (x86) or 1.12.0 alpha (from GIT)
Controller: Behringer CMD Micro

Same symptoms as for Esteban, i.e. "Play" loses all responsiveness. and can't be turned off via the controller, Mixxx' UI or the hotkey. The only solution is restarting Mixxx.

I think this has something to do with hotcueing. I use a custom midiscript that uses "hotcue_x_activate" and the "hotcue_X_set" part of the "...activate" mixxxcontrol works just fine. It's just the "hotcue_X_gotoandplay" part that breaks the "Play" button. I can still jump to hotcue_X, but pressing "Play/Pause" won't do anything.

Maybe I'm able to devise a workaround for now, but it would be nicer if the "Play/Pause" button got a bit more authority than any "hotcue" button. :)

[RJ Skerry-Ryan (rryan)]

This is likely a bug in the MIDI script that does not clear the hotcue_X_activate control so the deck is stuck in a "previewing" state. Hitting play in this state could get ignored because it is treated as latching the preview. As Daniel mentioned this might be less of a problem with master but it can still ignore at least one play press. I think the buggy MIDI script should be fixed instead of trying to detect this in Mixxx.

[Bjoern K. (amusing-random-alias)]

Thanks for the reply, Ryan.

The "Activate Hotcue" part in my midiscript is only triggered then the button is pressed (i.e. sending a "0x90" status) and it really just uses engine.setValue("[Channeln]","hotcue_x_activate",1).

Do I always need to define a "release", i.e. "0x80" event for each button? Would that, in my case, just constitute this: engine.setValue("[Channeln]","hotcue_x_activate",0) ?

[RJ Skerry-Ryan (rryan)]

Hi Bjoern,

Yep that's right, you need to map both press and release (at least for hotues) because of hotcue previewing. If you hold down the hotcue while stopped we preview from that hotcue (play while you hold the button, when you release it -> jump back to the hotcue and stop). If you hit play while previewing, we ignore the play and "latch" the play state so releasing the hotcue doesn't jump back to the hotcue. This is a feature on Pioneer CDJs and other devices that we implement.

Can you try to reproduce with a release added?

[Bjoern K. (amusing-random-alias)]

Yeah, I'll implement a release function and report back.

Does the release stuff only affect the hotcues?*
And "engine.setValue("[Channeln]","hotcue_x_activate",0)" is used to release, right?

*I have a button mapped for "go to playposition 0". Do I need a release event for that one, too?

[Esteban Serrano (e.serrano.r)]

This seems to be the reason why it happens in my case also. I will try to reproduce the bug with and without a fix added to the MIDI script, just to confirm (in a couple of days).

[Bjoern K. (amusing-random-alias)]

I'm trying to implement a release fuction, but no matter what I do, I don't have any luck with it at all (yet). Either it refuses to work or I run into this stupid issue.

[Bjoern K. (amusing-random-alias)]

Oh jeez, I've spent over two hours cursing and devising workarounds just to realize that a release event can't work if there's no hardware assignment in the controller's .xml for it.

The "hotcue_x_activate" mixxcontrol for the release works perfectly and the hotcue buttons now do what they're supposed to do (set hotcue, play when pressed, stop and return when released). No more blocking the "Play" button.

So no bug after all, just an ID10T error in my case. (I'm still laughing.)

[Esteban Serrano (e.serrano.r)]

I could reproduce the bug by pausing the song and then pressing a hotcue button, just as Ryan suggested. The fix was the same as for Bjoern (mapping the button release on the controller script), so now the bug (which was my fault after all) is fixed on mixxx v1.11.0 (x64).

I will be updating the MC2000 script on the forum shortly.

Thanks a lot,

Esteban

[RJ Skerry-Ryan (rryan)]

Great to hear the root cause is solved! Thanks for the help, everyone.

[naught101 (naught101)]

So... I have this problem with 1.12.0-alpha (build master r4737).

I have a Korg NanoPad. I've just done a very basic mapping with the wizard, to make the 16 pads correspond to the 4 hotcues on each deck (Yay, 4-deck!). This wizard-created mapping has this problem, and using one of the hotkeys results in a deck that can't be stopped. Is it possible to fix the wizard, so that it creates mappings properly? I can probably fix the problem manually, but it will occur for everyone else, and for ever new controller.

[RJ Skerry-Ryan (rryan)]

The problem is we can't currently tell the difference between a MIDI switch and a button.

The new wizard should have a checkbox that lets you flag that the button is a switch-style button so if it doesn't work in the "try it out" phase you can try checking that. Not a perfect solution I realize...

[Swiftb0y (swiftb0y)]

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