Run your first job
Submit a file, watch it split across your fleet, and understand what you are looking at while it encodes.
Use a real file, but not your most important one — something a couple of minutes long is ideal for a first run. A very short clip will not split into enough chunks to show distribution working.
You need at least one worker showing online on the Workers page. A worker still in pending approval will not pick anything up, and the job will sit in the queue looking stuck. See Add a worker.
Where the file needs to be#
You give the master a path, and the master has to be able to read it. This trips people up on the first job more than anything else.
| Your setup | What 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. It will serve the bytes each worker needs over the network for you. |
A path that exists on your laptop but not on the master is the most common first-job failure. The master is the machine that opens the file, not your browser.
Submit the job#
Open Submit in the sidebar. The flow is four steps, with two optional panels you can ignore for a first run.
Enter the path to your file. The master runs a probe against it and reads the container, duration, resolution, frame rate and audio layout.
If the probe fails, the message tells you why — usually a path the master cannot see. You are still allowed to submit, because the worker re-checks the path before encoding, but a failed probe on the first job almost always means the path is wrong.
Choose what you are making. Each preset card states what it is for and what it produces. Presets are the safe path — they carry tested settings rather than leaving you to assemble flags.
You can let TRNSCODE choose instead of picking yourself. The preset step offers a guided mode that narrows the library by what you are delivering, and an automatic mode that inspects the source and selects for you. For a first job, pick a preset by hand so you can see the relationship between what you chose and what came out.
Choose the output directory, the filename, and a name for the job. The file extension is set by the preset — a preset producing a QuickTime file will not let you write .mp4.
The output directory must be writable by the master, which is the machine that assembles the finished file.
The last screen shows what was detected in your source next to what the preset will produce, including an estimated output size.
If the preset declares expectations about its input and your source does not match them, a warning panel lists each mismatch. Read it. It is the difference between a file that is technically valid and one that is actually deliverable.
Two further panels are available from within the flow and are not part of the linear path: Advanced, for per-job overrides of what the preset would otherwise decide, and Localization. Leave both alone until you have a baseline encode you trust.
Watching it run#
On submit you land on the queue with your job at the top. Expand it to see the chunk map — one cell per chunk, coloured by the worker encoding it.
This is the clearest picture of whether distribution is working. What you want to see:
- Cells changing colour across several workers — the job is genuinely 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 it does.
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 real time, and the job stays open through it.
What a successful job looks like#
A job that completes has passed verification, not merely produced a file. The master checks the assembled output against what it expected: the duration must match the source within a one-frame tolerance, and if the source carried audio, the output must carry audio.
This is worth understanding because the failure it catches is the quiet one. FFmpeg can exit successfully having produced a file that is truncated or silent. A job reported complete has been checked for both.
For a first job, open the output in whatever you normally cut or review with. 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 is where truncation hides.
When it does not work#
| 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. Check it from the master, not from your own 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 there. It is the master's filesystem that matters, not the worker's. |