This is for consistency with the `blender_cmd` setting of Blender render
commands. The splitting is done so that extra CLI commands can be given
in the Manager config.
This requires FFmpeg to be installed (not just for the command, but also
for running the accompanying unit test). Because of this external
dependency, the worker has to declare task_type='video-encoding' in its
configuration file before it gets such tasks. This is not enabled by
default.
The 'may-i-run' endpoint may say 'no' to us running task X, but when the
response comes in and is handled the worker may already be working on task
Y. This case is now recognised, and the 'no' will be ignored.
This makes a clearer distinction between Flamenco tasks ('task') and
AsyncIO tasks ('future'). The AsyncIO Task class is a subclass of its
Future class.
This also means that we need a `tests/__init__.py` file; this file makes
py.test undertand what is our sources directory, and thus allows them to
`import flamenco_worker`. As a result, the test imports from tests/*.py
need to change to relative imports.
This prevents multiple subprocess commands running at once. They shouldn't
be doing that in the first place, but we have a strange bug where multiple
Blenders seem to be running on the same machine.
Cycles and other render engines produce a line of log for each object in
the scene. In the Spring project there are so many objects (leaves, twigs,
pebbles) that it chokes the Manager with logs.
For now we have some custom code to swallow those lines, in lieu of a
logging system that can handle those volumes properly.
I'm guessing the do_db_push() async function execution was starved by
other asyncio tasks, causing Python to remember all the to-be-queued
payloads in memory. By making the function synchronous this doesn't happen.
When the "may I run" system says "no", we shouldn't push a "canceled"
status to the Manager, as this could overwrite another valid status that's
there for some other reason.
This is a clone of the Flamenco repository from back in the days when
Server, Manager and Worker shared the same Git repository. This is the
commit where that ended, and they went their separate ways.
