Closed kripton closed 9 years ago
I assume you're using Linux.
I didn't yet check the source code but I assume that we either need to Re-Init all plugins after loading a project
That's exactly what is causing the issue, and that's why the -o option solves it.
When QLC+ is started, it sets the plugins to a configuration written in the .config/qlcplus/Q\ Light\ Controller\ Plus.conf file. When a project is then opened, QLC+ closes the currently open plugins and open the ones written in the project file. I guess the -o option doesn't do the first phase (haven't checked the code) Removing the .config/qlcplus file should solve the issue as well. At least one time.
In other words you have found an issue related to a fast close/open of a Enttec Pro device. Please keep in mind though that the "Enttec pro" doesn't do simultaneous input/output. Only the Pro MK2 does it cause it has a dual-UART micro inside.
Do you have any chance to build from sources with debug enabled (default) and paste the debug log here or on Pastebin ? Thanks
Thanks for your explanation Massimo! Yes, the assumption about Linux was correct. I installed QLC+ from source using Gentoo Linux' Portage system. However, using Qt4 the DEBUG build failed but I guess it's Qt fault's. Using Qt5 it works and I'll do some more tests / coding when I get access to the system and the dongles again.
And yes, we were using two ENTTEC USB DMX Pro devices, one for the input from the hardware light console and one for the output to the fixtures.
I've had a look at the code and I think I found something but didn't have the chance yet to test it. First I need to reproduce what you saw. Basically the only place in the enttecpro code where the input thread is stopped is in the class destructor: https://github.com/mcallegari/qlcplus/blob/master/plugins/dmxusb/src/enttecdmxusbpro.cpp#L52
Problem is that the class is never destroyed during a close/open sequence, so I think there's something wrong with that thread. I was convinced I had reimplemented the close method but instead I reimplemented only the open method.
I'll update you here when I work on it,
@kripton Should be solved now. I reproduced it and saw the input was not working anymore. Here's the fix: https://github.com/mcallegari/qlcplus/commit/080ef72940511a08b316b26cd18344c0ff29d2f0
Please note that it is on a branch cause I am working on a big structure change of the dmxusb plugin. In case, just patch your sources and let me know if it works for you too.
I hope to be able to merge the dmxusbmulti branch upstream soon.
[EDIT] The fix is on the master branch now. Just build the upstream sources
Thanks for looking into this and the fix Massimo! I didn't yet have access to the system but I'll let you know if it works now.
Closing this after 17 days with no feedback.
Problem occured with QLC+ 4.9.1, not git head
Description of the symptoms - longer story below:
This weekend we used QLC+ at one stage of a city festival. The day before we prepared the project (fixures, addresses, universe patching): One Enttec USB DMX Pro as output and one as input to use a DMX light desk as controller for QLC+ (not pass-through mode). While DMX input worked at the beginning, after a restart of the software (due to another bug) and opening the project, the input is no longer recognized. After many tries (switching both hardware DMX interfaces, checking the DMX desk, switching from libFTDI-0.1 to libFTDI-1.2, disabling the web server) we found out that it always works when QLC+ has been started with the empty project (add one slider and check using the Auto-Detect feature) but it no longer works when the project has been loaded (which takes about 1 second). So I assume that the connection to the dongle gets lost while QLC+ is busy opening the project. I tried to use OLA to communicate with the hardware and use the OLA-plugin to get the values into QLC+ but OLA didn't recognize the dongles at all (whyever, need to check later). We then switched to our fallback: the KORG nanoKONTROL2. Inputs from this device (ALSA MIDI) worked before and after loading the project. Fortunately we found another workaround: Specify the project to load on the command line ("-o" parameter). It seems that in this case, the project gets loaded before the plugin init and universe patching is done. So there is no pause that could break the connection to the interface.
I didn't yet check the source code but I assume that we either need to: