Run your first job
Submit a file, monitor its distribution across the fleet, and interpret the queue while it encodes.
Use a real source file, but not a critical one. A clip approximately two minutes long is ideal for a first run; a very short clip does not split into enough chunks to demonstrate distribution.
A screenshot walkthrough of this procedure is available at How-to: Submit a file.
The master must be activated before it accepts a submission. A master that has never been activated blocks new job submissions until its license is registered; the console banner names the state and links to the Licensing panel. See Licensing.
At least one worker must show online on the Workers page. A worker still in pending approval does not pick up work, and the job remains in the queue without progress. See Add a worker.
Source path requirements#
The job is submitted as a path, and the master must be able to read that path. This requirement is the most common source of first-job failures.
| Deployment | Path to enter |
|---|---|
| Everything on one machine | An ordinary local path on that machine. |
| Master and workers with a shared network volume | A path that resolves identically on every machine. This is the fastest arrangement; the source is never copied. |
| Workers with no shared storage | A path the master can read. The master serves the bytes each worker needs over the network. |
A path that exists on the submitting machine but not on the master is the most common first-job failure. The master is the machine that opens the file, not the browser.
Submit the job#
Open Submit in the sidebar. The flow is four steps — Source, Preset, Destination, Review — plus an optional Advanced step. Neither the Advanced step nor the localization delivery mode is needed for a first run.
Browse the master's filesystem with Browse master… or paste the path to the file. The step references the file in place by default — nothing is copied; a worker that can see the path reads it directly. Upload from this computer is collapsed beneath the path field, for a file that exists only on the current computer.
The path is carried forward; the master probes it when the Review step opens and reads the container, duration, resolution, frame rate and audio layout.
Select a preset for the intended deliverable. Each preset card states its purpose and its output. Presets carry tested settings and are the recommended path; assembling encoder flags by hand is not required.
The gallery is searchable: a category rail groups the presets by use, facet chips filter by codec, resolution, container and HDR, and the search field matches free text. The step also carries a delivery-mode choice; leave it at Single output for a first job.
The output directory pre-fills with the configured output directory; keep it for a first job. The filename and job name pre-fill from the source, and the file extension is set by the preset; a preset that produces a QuickTime file does not accept an .mp4 extension.
The output directory must be writable by the master, which is the machine that assembles the finished file.
The Review step opens a preview of the source — played natively when the browser can decode it, or through a low-resolution HLS proxy the master generates on demand for production codecs such as ProRes and DNxHR. A clip timeline below the preview sets trim and fade by dragging handles, and further adjustments are grouped into Audio, Framing, Look and NLE cards; leave all of them untouched for a first job.
The step shows the properties the probe detected in the source beside the properties the preset will produce, including an estimated output size.
If the probe could not read the path, the screen states the reason and still permits submission — but the master probes the source again at submission and refuses a source it cannot read. On a first job, a failed probe almost always indicates an incorrect path; correct it before submitting.
If the preset declares expectations about its input and the source does not match them, a warning panel lists each mismatch. Review every listed mismatch; these conditions determine whether the output is deliverable rather than merely valid.
One further step sits outside the numbered path: Advanced, which groups per-job overrides of settings the preset would otherwise decide — container, codec, resolution, frame rate, bitrate and the audio equivalents — into collapsible sections. Choosing Localization (territory delivery) on the preset step adds a territories step before Review. Leave both unchanged until a trusted baseline encode exists.
Monitor the job#
After submission, the queue opens with the new job at the top. Click the job to open its detail page; the Chunks tab shows the chunk map: one cell per chunk, coloured by the worker encoding it.
The chunk map is the clearest indicator of whether distribution is working. Interpret it as follows:
- Cells changing colour across several workers — the job is spread across the fleet.
- All cells one colour — only one worker is taking work. Either the others are not approved, or they lack the capability this preset needs.
- A long tail of one cell — a slow worker is holding the final chunk. The job cannot finish until that chunk completes.
The job is not finished when the last chunk turns complete. The master then joins the chunks, muxes the audio back in, and verifies the result. On a long source, this assembly stage takes measurable time, and the job remains open through it.
Completion criteria#
A job that completes has passed verification, not merely produced a file. The master checks the assembled output against the expected result: the duration must match the source within a one-frame tolerance, and if the source carried audio, the output must carry audio.
This check exists because FFmpeg can exit successfully having produced a file that is truncated or silent. A job reported complete has been checked for both conditions.
For a first job, open the output in the application normally used for editing or review. Check the beginning, a point in the middle, and the very end. Chunk boundaries are where a distributed encoder would show problems, and the end of the file is where truncation appears.
Troubleshooting#
| Symptom | Most likely cause |
|---|---|
| Job sits queued, nothing starts | No worker is online and approved. Check the Workers page. |
| Probe fails on the source | The master cannot read that path. Verify the path from the master, not from the submitting machine. |
| Only one worker takes chunks | Other workers are pending approval, or cannot produce the codec this preset needs. Compare their reported capabilities. |
| A worker never appears at all | Discovery did not reach it, or it was refused for being on a non-wired link. See Allowing non-wired workers. |
| Job fails at the end, after all chunks completed | Assembly or verification failed. The activity log carries the specific reason. |
| Output directory empty | The master could not write to the directory. The master's filesystem applies, not the worker's. |