Description
Since updating to 1.5.0-beta.14, StreamController crashes on every startup when
a Stream Deck is connected. The app detects the USB device but fails immediately
when reading the serial number via HID feature report.
This creates a crash loop: the hard crash (SIGABRT) leaves the hidraw device handle
open, so every subsequent start fails with "already connected to another instance"
until the USB cable is replugged — which just triggers the crash again.
Downgrading to the parent Flatpak commit (b4e16bf4...) fully resolves the issue.
Steps to Reproduce
- Update to 1.5.0-beta.14 via Flatpak
- Start StreamController with a Stream Deck MK.2 connected
- App starts, detects the deck via on_connect, then immediately crashes
Expected Behavior
App starts and deck is recognized normally (worked in all previous versions).
Actual Behavior
StreamDeck.Transport.Transport.TransportError: Failed to read feature report (-1)
File "DeckController.py", line 853, in get_deck_settings
return gl.settings_manager.get_deck_settings(self.deck.get_serial_number())
File "StreamDeckOriginalV2.py", line 107, in get_serial_number
serial = self.device.read_feature(0x06, 32)
raise TransportError("Failed to read feature report (%d)" % result)
After crash, subsequent starts produce:
ERROR | DeckManager:load_hardware_decks:129 - Failed to open deck.
Maybe it's already connected to another instance?
Root Cause Hypothesis
The issue appears to be related to the new Remote Deck / beta_resume_mode
introduced in beta.14. In DeckController.__init__, the deck is opened with
self.deck.open(beta_resume_mode=True), followed immediately by get_deck_settings()
which calls get_serial_number() → read_feature(0x06, 32).
The feature report read (HID report ID 0x06, 32 bytes = serial number) returns -1,
suggesting the device is opened in a state that doesn't yet support feature reports —
likely a timing or initialization issue introduced by the beta_resume_mode path.
Notably, the logs show:
INFO | DeckManager:init:78 - Beta resume mode: True
This flag appears to be set unconditionally in beta.14 (even without a remote deck
being used), which may be the regression trigger.
Environment
- OS: CachyOS Linux (Kernel 7.0.10-1-cachyos)
- StreamController: 1.5.0-beta.14 (Flatpak, system install)
Commit: cf05ced6b1902e1c98a6dd9087b17ad0484825f1
- Device: Elgato Stream Deck MK.2 (USB 0fd9:0080, hidraw)
- Last working version: Parent Flatpak commit b4e16bf436eeb84d...
Workaround
Downgrade to the parent Flatpak commit:
pkill -f StreamController
sudo flatpak update \
--commit=b4e16bf436eeb84d387cf8a34b0e6e6cdc7db0596c55580b6e55a78d3d25a892 \
com.core447.StreamController
flatpak mask com.core447.StreamController
Additional Notes
- Related open issue: #601 (settings don't persist, same version) — different symptom,
possibly same underlying instability in beta.14
- The Flatpak build subject references "Retrigger build (#36)" — unclear if this is
a build system issue or a code regression
Description
Since updating to 1.5.0-beta.14, StreamController crashes on every startup when
a Stream Deck is connected. The app detects the USB device but fails immediately
when reading the serial number via HID feature report.
This creates a crash loop: the hard crash (SIGABRT) leaves the hidraw device handle
open, so every subsequent start fails with "already connected to another instance"
until the USB cable is replugged — which just triggers the crash again.
Downgrading to the parent Flatpak commit (b4e16bf4...) fully resolves the issue.
Steps to Reproduce
Expected Behavior
App starts and deck is recognized normally (worked in all previous versions).
Actual Behavior
StreamDeck.Transport.Transport.TransportError: Failed to read feature report (-1)
File "DeckController.py", line 853, in get_deck_settings return gl.settings_manager.get_deck_settings(self.deck.get_serial_number()) File "StreamDeckOriginalV2.py", line 107, in get_serial_number serial = self.device.read_feature(0x06, 32) raise TransportError("Failed to read feature report (%d)" % result)After crash, subsequent starts produce:
ERROR | DeckManager:load_hardware_decks:129 - Failed to open deck.
Maybe it's already connected to another instance?
Root Cause Hypothesis
The issue appears to be related to the new Remote Deck / beta_resume_mode
introduced in beta.14. In DeckController.__init__, the deck is opened with
self.deck.open(beta_resume_mode=True), followed immediately by get_deck_settings()
which calls get_serial_number() → read_feature(0x06, 32).
The feature report read (HID report ID 0x06, 32 bytes = serial number) returns -1,
suggesting the device is opened in a state that doesn't yet support feature reports —
likely a timing or initialization issue introduced by the beta_resume_mode path.
Notably, the logs show:
INFO | DeckManager:init:78 - Beta resume mode: True
This flag appears to be set unconditionally in beta.14 (even without a remote deck
being used), which may be the regression trigger.
Environment
Commit: cf05ced6b1902e1c98a6dd9087b17ad0484825f1
Workaround
Downgrade to the parent Flatpak commit: