Just got this one through review, sharing it here in case it’s useful.
What it does:
Drop a long video (podcast, webinar, interview, lecture) into a Google Drive folder. It comes back as short vertical clips — cut on word boundaries, reframed to 1080x1920, captions burned in — saved to Drive and in a Sheet, with a Slack digest.
A few things to check in case you hit the same walls:
Sizing the Wait node. A fixed wait either stalls short videos or times out long ones. The workflow reads the source duration from Drive metadata and computes the wait from it, clamped between a min and a max. If Drive hasn’t finished analyzing the file there’s no duration field at all, so it falls back to the min.
Keeping the upload URL away from the LLM. The MCP server hands back a 64-char signed upload URL. An agent retyping that gives you a URL that looks perfect and 404s. So that step is plain HTTP + a regex over the SSE body.
Polling outside the agent. The render can take tens of minutes. If the agent polls, you burn tokens and hit rate limits on a long run. Wait node sleeps, then a separate agent reads the flow back exactly once.
The video processing runs on an MCP server we built (CNAPS.ai MCP), so transcription, clip selection, reframing and captioning are one credential instead of four vendors. Free tier is enough to test it. Setup guide: Connect CNAPS.ai to n8n — MCP Integration Guide
the wait-node sizing problem is the part i’d call out first, most vertical clip pipelines get this wrong on the first pass and either stall on a short video or time out on a long one exactly like you described. curious what happens on the rare case where drive genuinely never returns a duration for a longer file, does the min clamp still hold up fine or does that one end up needing a manual retry?
keeping the signed upload url away from the llm and doing plain http plus a regex over the sse body instead of letting an agent retype it is a detail that usually only gets fixed after a 404 upload shows up in production, not before.
Good question, and the honest answer is no — the min clamp doesn’t save you there.
If Drive never returns a duration and the file is genuinely long, you get
min_wait_minutes (6 by default), the render is still going when the Wait expires, and
the run ends in the failure branch: no clips, and a Slack message naming the wait that
was used. So it fails loudly rather than silently, but yes, it needs a re-run today.
That’s why the Code node returns the basis alongside the number:
wait_basis: sourceMin ? ‘measured from Drive metadata’
: ‘no duration on the file, used min_wait_minutes’
When it fails at 3am that one string tells you whether it was a metadata problem or a
genuinely slow render. Different fix each time.
Two things I’d change, and I think the second is the real answer:
Don’t trust the trigger payload. Drive usually populates videoMediaMetadata within a
minute or two of the upload finishing — the trigger just fires before that. A short
Wait plus a Drive “get file” ahead of the sizing node recovers most of these.
Make the read-back a bounded retry loop instead of a single shot. If the status comes
back still running, Wait 5 and read again, up to N times. That fixes both this case
and the genuinely-slow-render case.
And while we’re being honest about the defaults: max_wait_minutes is 45 with a
multiplier of 4, so anything over ~11 minutes of source gets clamped to 45 regardless of
what the metadata said. Fine for the short-source case I built it for, wrong for a
90-minute webinar. The bounded loop makes that clamp much less load-bearing, which is
the other reason it’s the better design. I’ll ship it that way.
And yes on the upload URL — that one cost me an evening. The failure looks like a
working URL, which is the worst kind.
Are you hitting this with long sources specifically? If the metadata gap is the common
case for you rather than the rare one, I’d rather fix it in the template than in a note.