FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

[Bug] 1.5.0-beta.14: TransportError "Failed to read feature report (-1)" on startup → crash → device locked · Issue #604 · StreamController/StreamController · GitHub

[Bug] 1.5.0-beta.14: TransportError "Failed to read feature report (-1)" on startup → crash → device locked #604

Description

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

  1. Update to 1.5.0-beta.14 via Flatpak
  2. Start StreamController with a Stream Deck MK.2 connected
  3. 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    • Status
      No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


    Back | FazBrowse Home | New Git URL