Repository navigation
Skip the plugin list request once the server leaves it unanswered - #97
Merged
Merged
Conversation
OpenRGB 1.0 in server mode accepts REQUEST_PLUGIN_LIST and never replies (jath03#94). The hotfix in 0.3.7 recovers by waiting for the 10 s socket timeout and reconnecting, but it does so on every update(), so each update costs about 10 s. Clients that poll, such as the Home Assistant integration, hold their connection for most of the time and queue every command behind it. Remember that the request timed out and skip it on later updates of the same client. Only a timeout sets the flag: a dropped connection still retries the request on the next update. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
10 of 21 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #94 and the 0.3.7 hotfix.
Problem
OpenRGB 1.0 in server mode accepts
REQUEST_PLUGIN_LISTand never answers. Since 0.3.7,update_plugins()recovers by waiting for the 10 s socket timeout and reconnecting. It does this on everyupdate(), so every update takes about 10 s even though devices and profiles answer in under half a second.This matters for clients that poll. The Home Assistant
openrgbintegration (which ships 0.3.7 since 2026.10) callsupdate()every 15 s while holding a lock. The connection is busy about 10.5 s out of every 25 s, so a profile change or light command waits up to 10 s in the queue.Change
OpenRGBClientremembers that the plugin list request timed out (plugin_list_unanswered) and skips it on later updates of the same client. Only a timeout sets the flag. If the connection drops during the request (OpenRGBDisconnectedwithout a timeout cause), the request is retried on the next update as before.Testing
Against a real OpenRGB 1.0 service on Windows (8 devices, protocol 4 negotiated), from the Home Assistant container:
update()×3Against a minimal fake SDK server:
REQUEST_PLUGIN_LIST: the first connect still takes 10 s, then updates take 0.00 s and the flag isTrue;False;False.flake8 (CI selection) and mypy give the same results as on
master.The first connection still pays the 10 s once. Avoiding that would need either a shorter timeout for this one request or a server-side fix.
🤖 Generated with Claude Code