Several Roku secret-menu sequences do not reliably open their menus when sent through tvctl remote send, even though the same sequences work from the physical Roku remote on the same TV.
Observed examples
Platform secret menu: home home home home home up right down left up
Wireless secret screen: home home home home home up down up down up
Dev settings menu: home home home up up right left right left right
Channel settings menu: home home home up up left right left right left
The bitrate override menu also did not work from the physical remote during testing, so that one may be a separate Roku-side issue.
Current implementation
tvctl currently sends Roku remote input through ECP keypress/... requests only.
Why this needs investigation
Roku's official ECP docs explicitly document keypress, keydown, and keyup commands as supported inputs, and the docs include a keyup/keydown example. This suggests some secret-menu sequences may require more faithful button event delivery than repeated keypress calls provide.
Relevant documented key names include Home, Up, Down, Left, Right, Rev, and Fwd, which match the keys already used by tvctl.
Likely next steps
Prototype Roku input delivery using keydown/... + keyup/... per key
Compare behavior against current keypress/... delivery
Check whether secret-menu sequences need different pacing or explicit press/release semantics
Keep normal navigation behavior unchanged unless the higher-fidelity mode proves better
Repro notes
Normal navigation and app control work
remote send --delay changes did not fix the affected secret-menu sequences
Tested on a Hisense Roku TV at 10.10.0.136
## Summary
Several Roku secret-menu sequences do not reliably open their menus when sent through `tvctl remote send`, even though the same sequences work from the physical Roku remote on the same TV.
## Observed examples
- Platform secret menu: `home home home home home up right down left up`
- Wireless secret screen: `home home home home home up down up down up`
- Dev settings menu: `home home home up up right left right left right`
- Channel settings menu: `home home home up up left right left right left`
The bitrate override menu also did not work from the physical remote during testing, so that one may be a separate Roku-side issue.
## Current implementation
`tvctl` currently sends Roku remote input through ECP `keypress/...` requests only.
## Why this needs investigation
Roku's official ECP docs explicitly document `keypress`, `keydown`, and `keyup` commands as supported inputs, and the docs include a keyup/keydown example. This suggests some secret-menu sequences may require more faithful button event delivery than repeated `keypress` calls provide.
Official docs: https://developer.roku.com/docs/developer-program/debugging/external-control-api.md
Relevant documented key names include `Home`, `Up`, `Down`, `Left`, `Right`, `Rev`, and `Fwd`, which match the keys already used by `tvctl`.
## Likely next steps
- Prototype Roku input delivery using `keydown/...` + `keyup/...` per key
- Compare behavior against current `keypress/...` delivery
- Check whether secret-menu sequences need different pacing or explicit press/release semantics
- Keep normal navigation behavior unchanged unless the higher-fidelity mode proves better
## Repro notes
- Normal navigation and app control work
- `remote send --delay` changes did not fix the affected secret-menu sequences
- Tested on a Hisense Roku TV at `10.10.0.136`
Follow-up test result:
Tried a prototype Roku `keydown/...` + short hold + `keyup/...` delivery path instead of plain `keypress/...`, with a configurable press duration (`75ms`).
Result: the tested secret-menu sequence still did **not** open the menu on the target TV.
Tested sequence:
- `home home home home home up right down left up`
Environment:
- Hisense Roku TV at `10.10.0.136`
- `remote.roku_key_mode = keydown_up`
- `remote.roku_press_duration_ms = 75`
- inter-key spacing still `200ms`
Conclusion so far:
- valid Roku key names are not the issue
- simple `keypress` vs `keydown`/`keyup` delivery alone did not fix it
- revisit later; secret-menu automation remains experimental / unreliable
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Several Roku secret-menu sequences do not reliably open their menus when sent through
tvctl remote send, even though the same sequences work from the physical Roku remote on the same TV.Observed examples
home home home home home up right down left uphome home home home home up down up down uphome home home up up right left right left righthome home home up up left right left right leftThe bitrate override menu also did not work from the physical remote during testing, so that one may be a separate Roku-side issue.
Current implementation
tvctlcurrently sends Roku remote input through ECPkeypress/...requests only.Why this needs investigation
Roku's official ECP docs explicitly document
keypress,keydown, andkeyupcommands as supported inputs, and the docs include a keyup/keydown example. This suggests some secret-menu sequences may require more faithful button event delivery than repeatedkeypresscalls provide.Official docs: https://developer.roku.com/docs/developer-program/debugging/external-control-api.md
Relevant documented key names include
Home,Up,Down,Left,Right,Rev, andFwd, which match the keys already used bytvctl.Likely next steps
keydown/...+keyup/...per keykeypress/...deliveryRepro notes
remote send --delaychanges did not fix the affected secret-menu sequences10.10.0.136Follow-up test result:
Tried a prototype Roku
keydown/...+ short hold +keyup/...delivery path instead of plainkeypress/..., with a configurable press duration (75ms).Result: the tested secret-menu sequence still did not open the menu on the target TV.
Tested sequence:
home home home home home up right down left upEnvironment:
10.10.0.136remote.roku_key_mode = keydown_upremote.roku_press_duration_ms = 75200msConclusion so far:
keypressvskeydown/keyupdelivery alone did not fix it