uDMX issue--not sending in QLC+ until I UNpatch device

[smc]

I have a few humble fixtures that I like to use on occasion and I have a cheap uDMX controller (Lixada--I know, get what pay for and all that) that I am trying to get working with QLC+.

When I patch my udmx device to my universe and adjust something, nothing happens. Until I unpatch; then the latest channel values get sent through until I either flip the output back to udmx or unplug the device. That's pretty weird and now I'm stumped.
This does not happen with Freestyler or the basic uDMX console program (but I really don't want to use those).
This does not appear to be version specific (I tried a few of the older releases and they did it too)
This does not appear to be OS specific (I prefer linux but I tested this in Windows too)

Originally I was guessing it was just crappy hardware or drivers but with all of the above that seems unlikely. I figure I've reasonably narrowed it down to QLC+. I also ran a search on the forums, and while it looks like there will be some fun timing issues in my future, I didn't actually find anything similar to this.

I'd be happy to provide lsusb dumps or anything else that could be useful. I don't have a DMX tester or much in the way of spare hardware though; I am better versed in computers than DMX.

[metamedian]

Hi,

Have you found a solution to this problem?

[red]

Hello!

I experience the same issue and want to give more information:

I'm using the Lixada USB-DMX512 uDMX Adapter with Debian Linux Buster Release and Q Light Controller Plus version 4.12.0

In QLC+ it's recognized as Anyma uDMX device ("This plugin provides DMX output support for Anyma uDMX devices")

I'm running it with with 16 Hz because i get better results than with the standard frequency.
In the config file:

Code: Select all

[udmx]
frequency=16

it works well for a few seconds ... and then suddenly:
(running qlcplus -d)

Code: Select all

uDMX: unable to write universe: error sending control message: Cannot send after transport endpoint shutdown
uDMX: unable to write universe: error sending control message: No such device
uDMX: unable to write universe: error sending control message: No such device
uDMX: unable to write universe: error sending control message: No such device
uDMX: unable to write universe: error sending control message: No such device
uDMX: unable to write universe: error sending control message: No such device
uDMX: unable to write universe: error sending control message: No such device
[... and so on ...]

... and QLC+ stops sending packages.
(There is a small LED on the USB-Device indicating the transfer)

I can manually resolve the issue by:
1.) Rescan uDMX hardware ("Do you wish to re-scan your hardware?" Dialog)
2.) unchecking and checking the uDMX Output in the Input Output Manager again
... but this is not practicable.


USB Debuggig:

Code: Select all

$ mount -t debugfs none_debugs /sys/kernel/debug
$ modprobe usbmon
$ lsusb
[...]
Bus 001 Device 027: ID 16c0:05dc Van Ooijen Technische Informatica shared ID for use with libusb
[...]
$ cat /sys/kernel/debug/usb/usbmon/1u > /tmp/usb-dmx-debug.txt

The attached log is starting with a freshly attached device ...
then it fails after a few seconds at 2508699236 ...
then i do the rescan-checkbox combo (I described above) in QLC+ ...
then it's running a pretty long time (1min?) ... at about 2518730043 ...
and then it fails again. at 2695648276 ...
End of log.

syslog ... When the hickup happens (log for 2x):

Code: Select all

Oct  8 14:16:05 whobert kernel: [14769.813111] usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd UDMXDevice rqt 64 rq 2 len 512 ret -71
Oct  8 14:16:32 whobert kernel: [14796.896598] usb usb1-port2: disabled by hub (EMI?), re-enabling...
Oct  8 14:16:32 whobert kernel: [14796.896608] usb 1-2: USB disconnect, device number 39
Oct  8 14:16:32 whobert kernel: [14796.896910] usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd UDMXDevice rqt 64 rq 2 len 512 ret -108
Oct  8 14:16:32 whobert kernel: [14797.173358] usb 1-2: new low-speed USB device number 40 using xhci_hcd
Oct  8 14:16:33 whobert kernel: [14797.337713] usb 1-2: New USB device found, idVendor=16c0, idProduct=05dc, bcdDevice= 1.02
Oct  8 14:16:33 whobert kernel: [14797.337717] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct  8 14:16:33 whobert kernel: [14797.337718] usb 1-2: Product: uDMX
Oct  8 14:16:33 whobert kernel: [14797.337720] usb 1-2: Manufacturer: www.anyma.ch
Oct  8 14:16:33 whobert kernel: [14797.337721] usb 1-2: SerialNumber: ilLUTZminator001
Oct  8 14:16:33 whobert mtp-probe: checking bus 1, device 40: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
Oct  8 14:16:33 whobert mtp-probe: bus: 1, device: 40 was not an MTP device
Oct  8 14:16:33 whobert mtp-probe: checking bus 1, device 40: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
Oct  8 14:16:33 whobert mtp-probe: bus: 1, device: 40 was not an MTP device
[...]
Oct  8 14:19:39 whobert kernel: [14983.844656] usb usb1-port2: disabled by hub (EMI?), re-enabling...
Oct  8 14:19:39 whobert kernel: [14983.844670] usb 1-2: USB disconnect, device number 40
Oct  8 14:19:39 whobert kernel: [14983.844888] usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd UDMXDevice rqt 64 rq 2 len 512 ret -71
Oct  8 14:19:39 whobert kernel: [14984.116330] usb 1-2: new low-speed USB device number 41 using xhci_hcd
Oct  8 14:19:40 whobert kernel: [14984.275647] usb 1-2: New USB device found, idVendor=16c0, idProduct=05dc, bcdDevice= 1.02
Oct  8 14:19:40 whobert kernel: [14984.275653] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct  8 14:19:40 whobert kernel: [14984.275656] usb 1-2: Product: uDMX
Oct  8 14:19:40 whobert kernel: [14984.275659] usb 1-2: Manufacturer: www.anyma.ch
Oct  8 14:19:40 whobert kernel: [14984.275662] usb 1-2: SerialNumber: ilLUTZminator001
Oct  8 14:19:40 whobert mtp-probe: checking bus 1, device 41: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
Oct  8 14:19:40 whobert mtp-probe: bus: 1, device: 41 was not an MTP device
Oct  8 14:19:40 whobert mtp-probe: checking bus 1, device 41: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
Oct  8 14:19:40 whobert mtp-probe: bus: 1, device: 41 was not an MTP device

... so for some reason the USB device is getting disabled and re-enabled by the system and QLC+ fails sending signals to the device after that.
Maybe because the USB device number changes?

I'm not a programmer and I'm not familiar with the qlc+ and plugin codebase, so i unfortunately can't help fixing this issue.
But I hope that this report helps someone to fix it

I can also help debugging.

cheers,
red

[red]

Oh ... and a weird behavior/fact/quickfix ...

When i keep outputting the usbmon debug log in a terminal ...

Code: Select all

cat /sys/kernel/debug/usb/usbmon/1u | cat

... it seems that the Lixada USB-DMX512 Adapter is running much more stable. (no disabling & re-enabling of the usb device ...)