[Bug Fix]: Stabilize resume by keeping controllers alive during transient HID errors by getjump · Pull Request #526 · StreamController/StreamController · GitHub
Skip to content

[Bug Fix]: Stabilize resume by keeping controllers alive during transient HID errors#526

Open
getjump wants to merge 1 commit into
StreamController:mainfrom
getjump:fix/resume-stability
Open

[Bug Fix]: Stabilize resume by keeping controllers alive during transient HID errors#526
getjump wants to merge 1 commit into
StreamController:mainfrom
getjump:fix/resume-stability

Conversation

@getjump

@getjump getjump commented Jan 7, 2026

Copy link
Copy Markdown
Contributor

Background

After suspend/resume, Stream Deck HID handles can temporarily fail (“No HID device”), even with the Use new resume mode (beta) flag turned ON. The previous
behavior removed controllers after repeated touchscreen transport errors, which triggered re-enumeration against
devices that were not yet ready and led to crashes/races.

Changes:

  1. Keep controllers alive on repeated touchscreen transport errors instead of removing/reconnecting.
  2. Guard update_all_inputs() and tick_actions() when active_page is None to avoid resume-time crashes.

Result

The app now survives transient HID failures and recovers without process restarts or race-condition
exceptions.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if we want to remove the ability to entirely reset the decks. If the error is real, and not transient, we would never attempt to reset the deck. One could make an argument for bumping this up from 5 to higher number possibly, but as I've never experience this issue will need to rely on @Core447 for input

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@getjump Also never had problems with the resume mode. But your fix should still work, if we keep the original logic where it removes the deck after too many errors, right? But as ImDevinC suggested, we could bump the number to maybe 10?

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

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

3 participants