NZXT Smart Device - spectrum-wave mode turns LEDs off about liquidctl

[jonasmalacofilho]

Thanks for opening the issue and providing this information. Though I notice that liquidctl status has failed too. I recall that it worked before, did you ran liquidctl initialize after turning on the computer?

To be clear: I don't expect this to be the issue with the Spectrum Wave mode, but it might change the specific failure and debug output I need to investigate.

[hst12]

It works when doing liquidctl initialize first! I didn’t realise that the initialize was necessary since other modes worked okay without it.

Here is the output:

C:\WINDOWS\system32>liquidctl initialize
Exception ignored in: <function _AutoFinalizedObjectBase.__del__ at 0x0000027B0E790158>
Traceback (most recent call last):
  File "c:\program files\python37\lib\site-packages\usb\_objfinalizer.py", line 84, in __del__
    self.finalize()
  File "c:\program files\python37\lib\site-packages\usb\_objfinalizer.py", line 144, in finalize
    self._finalizer()
  File "c:\program files\python37\lib\weakref.py", line 548, in __call__
    return info.func(*info.args, **(info.kwargs or {}))
  File "c:\program files\python37\lib\site-packages\usb\_objfinalizer.py", line 104, in _do_finalize_object_ref
    obj._do_finalize_object()
  File "c:\program files\python37\lib\site-packages\usb\_objfinalizer.py", line 71, in _do_finalize_object
    self._finalize_object()
  File "c:\program files\python37\lib\site-packages\usb\backend\libusb1.py", line 604, in _finalize_object
    _lib.libusb_unref_device(self.devid)
OSError: exception: access violation writing 0x0000000000000024

C:\WINDOWS\system32>liquidctl set led color spectrum-wave
Exception ignored in: <function _AutoFinalizedObjectBase.__del__ at 0x0000024CAC0C0158>
Traceback (most recent call last):
  File "c:\program files\python37\lib\site-packages\usb\_objfinalizer.py", line 84, in __del__
    self.finalize()
  File "c:\program files\python37\lib\site-packages\usb\_objfinalizer.py", line 144, in finalize
    self._finalizer()
  File "c:\program files\python37\lib\weakref.py", line 548, in __call__
    return info.func(*info.args, **(info.kwargs or {}))
  File "c:\program files\python37\lib\site-packages\usb\_objfinalizer.py", line 104, in _do_finalize_object_ref
    obj._do_finalize_object()
  File "c:\program files\python37\lib\site-packages\usb\_objfinalizer.py", line 71, in _do_finalize_object
    self._finalize_object()
  File "c:\program files\python37\lib\site-packages\usb\backend\libusb1.py", line 604, in _finalize_object
    _lib.libusb_unref_device(self.devid)
OSError: exception: access violation writing 0x0000000000000024

[jonasmalacofilho]

It works when doing liquidctl initialize first! I didn’t realize that the initialize was necessary since other modes worked okay without it.

I did not know that either! I mostly run initialize anyway to use (or test) the fan channels.

The requirement probably has something to do with the device needing to know the exact length of the strip to render this effect; the type and number of LED accessories is also learned during the initialization.

I will add to the documentation that some effects require the device to be fully initialized.

---

The access violation errors from _lib.libusb_unref_device(self.devid) are probably caused by a know issue between PyUSB and libusb. I assume you are running libusb 1.0.22 or later, am I correct?

[hst12]

That makes sense. Where the number of LEDs are specified for example:
liquidctl set led color super-fixed 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 202020 202020 202020 202020 202020 202020 202020 202020 202020 202020
This works without needing the initialize and I'm using it in a startup script.

I'm using libusb 1.0.22

[jonasmalacofilho]

For future readers, here is the TL; DR...

While some features might work before that, it is necessary to initialize the Smart Device or Grid+ V3 after powering on or if there have been hardware changes.

# liquidctl initialize

---

The latest commits (most notably 73ea48c) should have improved the documentation around the original issue, as well as the access violation with PyUSB ✕ libusb v1.0.22.