Priorities for runners #5079

New issue

Open

opened 2026-02-22 11:02:22 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-22 11:02:22 -05:00

Owner

Originally created by @normen on GitHub (Jul 17, 2023).

Describe the problem to be solved

I would like to use one runner as the "primary" runner while other registered runners should only be used when the primary runner is not available or its queue is full.

Describe the solution you would like

To achieve the mentioned result it would be great to have a priority option per runner that would indicate to peertube which of the runners should be tried first.

Originally created by @normen on GitHub (Jul 17, 2023). ### Describe the problem to be solved I would like to use one runner as the "primary" runner while other registered runners should only be used when the primary runner is not available or its queue is full. ### Describe the solution you would like To achieve the mentioned result it would be great to have a `priority` option per runner that would indicate to peertube which of the runners should be tried first.

deekerman added the

Type: Feature Request ✨

Component: Runners

labels

2026-02-22 11:02:22 -05:00

deekerman commented

2026-02-22 11:02:28 -05:00

Author

Owner

@tio-trom commented on GitHub (Jul 24, 2023):

I was about to say the same thing. Some runners are more important than others, or more reliable. Perhaps a priority index with 1 to 5 or something like that. Try the 1 first, if not available move to level 2, and so on.

@tio-trom commented on GitHub (Jul 24, 2023): I was about to say the same thing. Some runners are more important than others, or more reliable. Perhaps a priority index with 1 to 5 or something like that. Try the 1 first, if not available move to level 2, and so on.

deekerman commented

2026-02-22 11:02:35 -05:00

Author

Owner

@manicphase commented on GitHub (Feb 29, 2024):

I've been playing with the runners and come up with a very basic but functional way of managing priorities. I've added a variable called responseDelay which can be set under [jobs] in config.toml. This number represents the amount of milliseconds a runner should wait before attempting to claim a job. A higher number means a lower chance of winning the race to pick up a job.

the change can be found here: https://github.com/Chocobozzz/PeerTube/compare/develop...manicphase:PeerTube-p2p-runner:add-response-delay-to-runners

@Chocobozzz can I create a pull request for this?

@manicphase commented on GitHub (Feb 29, 2024): I've been playing with the runners and come up with a very basic but functional way of managing priorities. I've added a variable called `responseDelay` which can be set under [jobs] in `config.toml`. This number represents the amount of milliseconds a runner should wait before attempting to claim a job. A higher number means a lower chance of winning the race to pick up a job. the change can be found here: https://github.com/Chocobozzz/PeerTube/compare/develop...manicphase:PeerTube-p2p-runner:add-response-delay-to-runners @Chocobozzz can I create a pull request for this?

deekerman commented

2026-02-22 11:02:35 -05:00

Author

Owner

@Chocobozzz commented on GitHub (Mar 1, 2024):

@manicphase thanks for the interesting idea! I was more thinking about using the WS available-jobs where the peertube instance tries to send the event to runners by priority.

But the question is: do we assign priority on runner side or on the peertube instance?

@Chocobozzz commented on GitHub (Mar 1, 2024): @manicphase thanks for the interesting idea! I was more thinking about using the WS `available-jobs` where the peertube instance tries to send the event to runners by priority. But the question is: do we assign priority on runner side or on the peertube instance?

deekerman commented

2026-02-22 11:02:35 -05:00

Author

Owner

@manicphase commented on GitHub (Mar 1, 2024):

From my perspective it seems like allowing the runner to decide whether it picks up a job is a better option. There's other considerations beyond just arbitrary priority too.

I've been experimenting using some old raspberry pis and with those you can hit limitations such as quickly running out of disk space or being too slow to do live transcoding above certain resolutions.

To me, having the instance send all the metadata to the runner and letting the runner decide whether or not it can do the job seems like it would make it easier to quickly deal with a wider range of issues than having the instance manage the runners. The theoretical problem with this is that it could also lead to jobs not being picked up, like your main workstation might by chance claim a job to transcode at 720p and your micro computer or VPS might then refuse to pick up the 1080p job.

@manicphase commented on GitHub (Mar 1, 2024): From my perspective it seems like allowing the runner to decide whether it picks up a job is a better option. There's other considerations beyond just arbitrary priority too. I've been experimenting using some old raspberry pis and with those you can hit limitations such as quickly running out of disk space or being too slow to do live transcoding above certain resolutions. To me, having the instance send all the metadata to the runner and letting the runner decide whether or not it can do the job seems like it would make it easier to quickly deal with a wider range of issues than having the instance manage the runners. The theoretical problem with this is that it could also lead to jobs not being picked up, like your main workstation might by chance claim a job to transcode at 720p and your micro computer or VPS might then refuse to pick up the 1080p job.