Add new form of preparation commands that runs before checking for displays

[FiveYellowMice]

Description

This PR attempts to a new form of preparation commands that runs before checking for displays, to solve feature request https://github.com/orgs/LizardByte/discussions/283 . This will include a minor refactor as suggested in this comment.

Hopefully this can open up doors for adding "on stream pause/resume" commands in the future.

Issues Fixed or Closed

https://github.com/orgs/LizardByte/discussions/283

Type of Change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Dependency update (updates to dependencies)
• [ ] Documentation update (changes to documentation)
• [ ] Repository update (changes to repository files, e.g. .github/...)

Checklist

• [ ] My code follows the style guidelines of this project
• [ ] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

[sonarqubecloud[bot]]

Quality Gate failed

Failed conditions
2 New issues
2 New Code Smells (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[ReenigneArcher]

Thank you for the PR!

I think we could just move when the prep commands run instead of introducing another type of prep commands?

Edit: You might be interested in helping with this roadmap item https://github.com/LizardByte/roadmap/issues/38 ... if not, this PR can still be accepted in the meantime.

[ReenigneArcher]

@FiveYellowMice any response?

[FiveYellowMice]

I was travelling last week, hence the silence.

Anyways, there are 2 reasons for a new type of prep commands:

1. If prep commands are simply moved to run before display setup, it would technically a breaking change. If someone have their commands assuming display to be already setup, they will fail. This sounds like a super specific scenario, I don't know how relavant this is, but I didn't want to make a breaking change without being told it's acceptable to do so.

2. According to a comment by Nonary:

   When the day comes for extending prep commands (to do things like on stream pause, on stream resume, etc) it's definitely a consideration to add a before encoder initialize command I guess.

   It seems having multiple types of prep commands is going to be desirable eventually. So I figured that it would be a good idea for this PR to be laying some groundwork for adding stream pause/resume commands. i.e. factoring out prep command running logic, and accomodating multiple types of prep commands in the web UI.

Helping out with the roadmap sounds interesting. It seems to encompass the aforementioned "day for extending prep commands". It doesn't seem clear what I can do for the roadmap, though, just by reading its thread. What can I do?

[ReenigneArcher]

If someone have their commands assuming display to be already setup, they will fail.

That's a good point. I was not considering those who are changing resolutions for example. My bad...

Expanding on the roadmap entry here. This is just some brainstorming, nothing written in stone. We probably need a few different stages when a command can run.

• pre display check - this PR (needed to enable displays before streaming)
• post display check - current prep commands
• pre stream start - current main command
• post stream start - nothing available currently
• stream pause / disconnect - nothing available currently
• stream quit / end / termination - current undo commands
• additional user connects to stream - nothing available currently

And the commands and do/undo commands to be refactored a bit. In the apps config it should probably just be a sequence of commands.

e.g.

"commands": [
  {
    "detached": True/False,
    "elevated": True/False,
    "ignore_error": True/False,
    "log_file": "e.g. my_command.log",
    "name": "Friendly name",
    "run": "terminal command to run",
    "shell": "shell to use, e.g. auto, bash, cmd, pwsh, etc.",
    "stage": "the point when the command should run",
    "working_directory": "path to start in"
  }
]

These would be listed in the order that they should run. In the c++ at each stage loop over the list in order and only run the command if the stage matches the stage we're at.

[FiveYellowMice]

Thanks for the additional info. I guess in this case, I can keep the original plan for this PR, i e. adding a new type of commands, but keep this future roadmap in mind. Then think about what to do with the roadmap afterwards.

There does seem to be a backwards incompatibility with the roadmap though. Currently, the undo prep commands are run in reverse order of definition, and they will only run if the corresponding do command has exited successfully. These 2 features allows for graceful exit should one of the do commands fail. The proposed refactor will discard these 2 features. Has this been discussed and deemed acceptable?

If not, my opinion is to keep the commands in do/undo pairs, and extend the pairs to have more type

• Pre-display setup / Post-display revert
• Post-display setup / Pre-display revert
• Pre-stream start / Post-stream stop
• etc.

But that probably makes things more confusing to the user. Some types of commands (like detached commands) don't fit into a do/undo pair, so they will not be in a pair, which means more types of data structures, more complexity.

On Mon, 5 May 2025, 05:07 ReenigneArcher, @.***> wrote:

ReenigneArcher left a comment (LizardByte/Sunshine#3821) https://github.com/LizardByte/Sunshine/pull/3821#issuecomment-2849370961

If someone have their commands assuming display to be already setup, they will fail.

That's a good point. I was not considering those who are changing resolutions for example. My bad...

Expanding on the roadmap entry here. This is just some brainstorming, nothing written in stone. We probably need a few different stages when a command can run.

• pre display check - this PR (needed to enable displays before streaming)
• post display check - current prep commands
• pre stream start - current main command
• post stream start - nothing available currently
• stream pause / disconnect - nothing available currently
• stream quit / end / termination - current undo commands
• additional user connects to stream - nothing available currently

And the commands and do/undo commands to be refactored a bit. In the apps config it should probably just be a sequence of commands.

e.g.

"commands": [ { "detached": True/False, "elevated": True/False, "ignore_error": True/False, "log_file": "e.g. my_command.log", "name": "Friendly name", "run": "terminal command to run", "shell": "shell to use, e.g. auto, bash, cmd, pwsh, etc.", "stage": "the point when the command should run", "working_directory": "path to start in" } ]

These would be listed in the order that they should run. In the c++ at each stage loop over the list in order and only run the command if the stage matches the stage we're at.

— Reply to this email directly, view it on GitHub https://github.com/LizardByte/Sunshine/pull/3821#issuecomment-2849370961, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFIDUYMADH7LO6C57352V324ZQQZAVCNFSM6AAAAAB37S6OX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBZGM3TAOJWGE . You are receiving this because you were mentioned.Message ID: @.***>

[Nonary]

@FiveYellowMice I totally get what you mean by complexity and confusion with the prep command redesign. But fortunately, AI is rather quite insane right now.

... So yeah, that's my next project to implement into Sunshine a complete rework to prep commands.

[Nonary]

Submitted my prep command redesign in draft, this will likely replace this PR once I continue working on it.

https://github.com/LizardByte/Sunshine/pull/4023

Right now, it's at a somewhat usable state but may drastically change over the next few days.

[LizardByte-bot]

It looks like this PR has been idle for 90 days. If it's still something you're working on or would like to pursue, please leave a comment or update your branch. Otherwise, we'll be closing this PR in 10 days to reduce our backlog. Thanks!

[LizardByte-bot]

This PR was closed because it has been stalled for 10 days with no activity.