StreamDeck.Transport.Transport.TransportError: Failed to write feature report (-1)

[danielskowronski]

Describe the bug
The issue is very unstable: after at least one open-reset-write-reset-close cycle, from time to time, I can no longer control Stream Deck Neo until the device is physically reconnected. The error is Failed to write feature report (-1) during feature report sending.

This is similar to #134, but that report was for a platform-specific scenario when issue occurred automatically after some time and only reboot could solve the issue.

Full output:

Traceback (most recent call last):
  File "/home/daniel/rpideck/rpideck.py", line 193, in <module>
    deck.reset()
  File "/home/daniel/.local/lib/python3.11/site-packages/StreamDeck/Devices/StreamDeckNeo.py", line 120, in reset
    self.device.write_feature(payload)
  File "/home/daniel/.local/lib/python3.11/site-packages/StreamDeck/Transport/LibUSBHIDAPI.py", line 405, in write_feature
    return self.hidapi.send_feature_report(self.device_handle, payload)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/daniel/.local/lib/python3.11/site-packages/StreamDeck/Transport/LibUSBHIDAPI.py", line 265, in send_feature_report
    raise TransportError("Failed to write feature report (%d)" % result)
StreamDeck.Transport.Transport.TransportError: Failed to write feature report (-1)
python3: ../../libusb/os/threads_posix.h:58: usbi_mutex_destroy: Assertion `pthread_mutex_destroy(mutex) == 0' failed.
python3: ../../libusb/os/threads_posix.h:46: usbi_mutex_lock: Assertion `pthread_mutex_lock(mutex) == 0' failed.
Aborted

To Reproduce
Run example_neo.py, close it and from time to time it'll crash and block device until it's reconnected.

StreamDeck Information
Stream Deck Neo

System Information

• library version 0.9.6
• Raspberry Pi 3B+ (aarch64)
• Raspbian 64-bit -> `Linux rpi 6.6.74+rpt-rpi-v8 maintenance: Strem -> Stream #1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27) aarch64 GNU/Linux
• libhidapi-libusb0:arm64=0.13.1-1
• libusb-1.0-0:arm64=2:1.0.26-1

Investigation status
I'm in the process of verifying the exact triggers for this bug, but wanted to let you know that issue exists.

I can spin up Linux VM on some other architecture, but it may be difficult to get exactly the same library configuration. However, as tested for #134 the same issue was happening on Raspbian and Ubuntu (with newer kernel and libusb 1.0.27) so I suspect it's not related to libusb, but either to DWC2 controller or this library.

I tried to add hid_error support to learn why exactly report can't be sent, but on Linux it always returns hid_error is not implemented yet

[danielskowronski]

I left a simple script based of example_neo.py (with addition of sched based clock) running for a night in a bash loop, and it crashed a couple of dozens of times, eventually recovering after a few attempts. This time, it was always on self.hidapi.write(self.device_handle, payload) returning -1.

Maybe it would be enough to add an option to retry failed writes? It may be related to poor performance of RPi-like systems and the limiting factor is hardcoded timeout in libhidapi as discussed in libusb/hidapi#493

If that fails, perhaps it'd be best to reconsider adding hidraw as a secondary choice because now even old RPi 3B+ has kernel 6.6 available.
(ref: #124)

[danielskowronski]

I think I have reasonably reproducible test scenario: spam Stream Deck with button colour set while physically pressing buttons. After less than a minute, device freezes and requires physical reset. However, this only happens on RPi and not on Mac.

I tested that with HIDAPI using hidapitester on RPi and Mac and HIDRAW using hidraw-poke on RPi only.

Since the looped commands were using exact payloads as this library, it's ruled out as a culprit. Moreover, same behavior is visible on both HIDAPI and HIDRAW, which suggests that #124 wouldn't help.

Unless there's some very weird correlation, I'm assuming the fault originates either in LibUSB or RPi 3B+ platform (DWC2 USB host, very slow performance etc.)

While this library is not at fault, it's still worth noting that it seems not to work on Linux LibUSB on Raspberry Pi (at least with Stream Decks Neo and Mk.2)

I'll probably buy newer RPi-like board with same CPU architecture and report back.

---

For reference, here are my primitive test scripts that are deliberately in pure portable bash.

HIDRAW:

#!bash
date
while true; do
  for i in 0 1 2 3 4 5 6 7 8 9; do
    k=`printf '%02x' $i`
    r=`printf '%02x' $((1 + $RANDOM % 255))`
    g=`printf '%02x' $((1 + $RANDOM % 255))`
    b=`printf '%02x' $((1 + $RANDOM % 255))`

    hidraw-poke --write feature --id 3 --device /dev/hidraw0 06 $k $r $g $b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    if [[ $? -ne 0 ]]; then
      date
      exit 1
    fi
  done
done

HIDAPI:

#!bash
date
while true; do
  for i in 0 1 2 3 4 5 6 7 8 9; do
    output="`hidapitester --vidpid 0FD9/009A --open --length 32 --send-feature "3,6,$i,$((1 + $RANDOM % 255)),$((1 + $RANDOM % 255)),$((1 + $RANDOM % 255))" --close`"
    echo $output
    echo $output | grep "32 bytes"
    if [[ $? -ne 0 ]]; then
      echo $output
      date
      exit 1
    fi
  done
done

[danielskowronski]

On Orange Pi 3B (RK3566) running Ubuntu 24.04 the issue is not reproducible on both 2.0 and 3.0 ports.

Unless we can easily interact with LibUSB to reset device (either to kick HIDAPI or recover stuck Stream Deck itself), I'd add better handling of write failure.