Cancelling, deleting or quitting during a video export does not always stop it #790

What goes wrong

Three gaps let a video export keep running after the person asked it to stop. (1) The cancel and delete checks are not made while the server tests encoders before the render (up to about two minutes on Linux). (2) run_video_render starts ffmpeg without first checking whether the render was cancelled. (3) On Windows, the desktop app stops the backend by killing it, so the shutdown code that cancels running renders never runs.

Who is affected

Anyone who cancels or deletes a take right after pressing Export, and Windows desktop users who quit during an export.

How to see it

1. Press Export MP4 on a take, then press Cancel at once (or delete the take, or the song).
2. On a machine where the encoder test is not cached, the test still runs to its end before the cancel is seen.
3. On Windows desktop, quit the app while a video is being made. ffmpeg may continue for up to the render timeout (60 minutes) and leave a temporary file.

Evidence

• app/api/takes.py:1531-1535 runs video_encoder.choose in a thread with no cancel hook.
• app/pipeline/take_render.py:545 creates the process; the first cancelled() check is at :576, inside the polling loop.
• app/main.py:272-274 cancels renders in the lifespan shutdown.
• desktop/src-tauri/src/main.rs:3770-3804 (stop_backend) sends SIGTERM and waits only on Unix; on Windows it goes straight to child.kill().
• Whether ffmpeg outlives its parent on Windows has not been run.

Constraints for anyone fixing it

• A change to main.rs changes the desktop shell binary. Read desktop-update-gate first: it can send every desktop install to a full download instead of an in-app update.
• Windows, macOS and Linux behave differently here; only Unix has a graceful stop today.
• Startup already sweeps stale render temp files (take_render.py:505), which limits the damage of a hard kill.

Origin

NEW in 0.21.0 (the render path, 6504500); the Windows quit path is older. Found on the big-release branch (draft pull request #784); the work is not released yet.

Possible direction

Check the cancel flag before spawning ffmpeg and between probe candidates. For Windows, ask the backend to cancel renders over HTTP before the kill, or put ffmpeg in a job object that ends with the backend.

Verified by

read; the Windows effect is INFERRED, not run.