check busy nodes and resync + start if selected when batch is submitted

[qcdebug]

This looks like great easy-to-use software for self-hosted blender farms.

I'd like to see the software retry all busy nodes periodically and sync/start rendering when they are determined to be free.
I encountered this on my desktop earlier because blender desktop was already running a test render that I forgot about.

This along with the sync baked files, or maybe cause a bake on the render nodes enhancement and I can see this software being used for almost any project imaginable.

Thanks for considering this request, I understand this is free software and I'm appreciative that you want to support the community like this.

[LogicReinc]

Sync bake files is hopefully planned in the near future, its just hard to find time, as it needs to be part of a bigger rework.

Retrying busy nodes is a bit of an edge case bordering outside of the scope of the project as it implies concurrent usage by multiple clients. The main reason being that BlendFarm does not have a centralized authority, and assumes the client has full (and sole) access to the render nodes. It can probably be added in a hacky way where each client tries to gain control over nodes, but it would just result in a fight between clients to get a lock on. And since a client needs a lock on all requested nodes, it will be hard. Render nodes don't actually know about each other's existence and they can't reliably inform each other on their state. This is why it is considered a bit outside of the scope of BlendFarm, as resolving it will likely be hacky and unreliable.

At some point I planned to make a Professional/Studio version of BlendFarm that has a centralized server to manage queues, concurrent usage, multi-user and such. But was unsure if there was enough interests and time to properly maintain it. BlendFarm already cost a significant amount of time to make. Hence I dropped it.

[qcdebug]

Thanks for the detailed explanation, I was thinking something simpler, though I can’t claim to understand how the queuing system works to know if it would work.

Take a loop of busy nodes and wait for them to return a response of ready then do the already existing process of sync and start handing out available frames waiting to them in the process as what I would expect is normal.

I have been told constantly that what I propose is never that easy and I’m not a programmer so I’d have to agree with that. If it’s as hard as you describe then I’ll happily cancel and restart my renders as needed when I clear up my desktop from being busy. If you do ever decide to make a studio version of this I do educational renders for people and that would absolutely be a software I’d be interested in.

EDIT: Removed email metdata*

[LogicReinc]

@qcdebug The scenario you describe is indeed the hacky way I described above. For animation queues it might work, as each node renders the entire frame, but for most other scenarios, a client needs a lock on all nodes. So you get a scenario where client 1 and client 2 may obtain locks on half the nodes, which then either causes them to both be deadlocked, or you might get the scenario where client 1 or 2 constantly gets all acquired locks.

I can think about the animation scenario but it would likely still need some changes, as most code is written to assume they get control over the nodes during the full duration of the render, not being stopped mid-way by another node having control.

[LogicReinc]

After giving it some thought, I suspect that if its constraint to queue rendering it might be a doable feature in the near-future. Though I can't give you a timeframe.

[qcdebug]

You are correct that I assumed this was useful in animation and indeed I think this would ONLY be useful on animation-related renders. I am in no hurry with the timeline, I greatly appreciate your consideration of this request.