Download failures say which yt-dlp produced them

[chiragjangiir]

What this changes

A download that fails now names the yt-dlp that produced it, and adds that a
newer yt-dlp may already have the fix when the failure looks like the site
changing under the extractor.

Refs #39 — deliberately not Fixes, see below.

Why

yt-dlp is collected into the installer at build time (clips-studio.spec),
while Twitch, Kick and YouTube change things regularly and yt-dlp fixes them
within days. So a site change breaks one platform for every installed copy
until the next release, and the failure itself says nothing about the version
that hit it. This is what a user gets today for an extractor break, captured
from main:

ERROR: [kick] 1a2b3c4d: Unable to extract video data; please report this issue
on https://github.com/yt-dlp/yt-dlp/issues?q= . Confirm you are on the latest
version using  yt-dlp -U

Nothing there identifies the copy in use, so "Kick stopped working" cannot be
triaged without asking for a Feedback Hub report, and a user has no way to know
the fix already exists upstream. KNOWN-ISSUES.md explains the situation, but
only to someone who goes looking — the failure says nothing. #39 notes that
option 1 is worth doing regardless of the other two, and it is what this does.

Every platform's download already passes through one function
(sources/dispatch.download), so the version travels with the failure from one
place rather than three. The note reads from yt_dlp.version.__version__ at
runtime — the same import server/feedback.py uses — so it reports the bundled
copy in an installed build, and nothing is hard-coded:

Clips Kitty's bundled yt-dlp is 2026.08.19. This reads like a change on the
site, which yt-dlp fixes within days — but the copy inside the app is fixed at
build time, so a newer yt-dlp may already have the fix:
https://github.com/yt-dlp/yt-dlp/releases

Only evidence of an extractor change gets that suggestion: yt-dlp's own wording
(unable to extract, no video formats found, unsupported url,
nsig extraction failed) plus the Confirm you are on the latest version hint
it prints with those errors. A timeout or a sign-in wall gets the version as
context and no claim, because a newer yt-dlp would not have helped and pointing
someone at one moves them further from the answer.

How you tested it

• npm run typecheck passes (in ui/)
• Tried the affected flow in the running app
• Tested on a real video: platform and length:

None of the three apply: this touches no ui/ file, and it changes no clipping,
tracking, caption or rendering behaviour. It was not run against a real video
because it does not need one — no download is made anywhere in the change or its
tests.

What was run, from the repository root:

Command	Result
pytest — no yt-dlp (the CI Python job's environment)	2345 passed, 482 skipped
pytest — with yt-dlp 2026.08.19 and defusedxml	2416 passed, 473 skipped
pytest tests/test_ytdlp_failure_diagnostics.py — no yt-dlp	12 passed, 4 skipped
pytest tests/test_ytdlp_failure_diagnostics.py — with yt-dlp	16 passed
ruff check .	All checks passed
python -m compileall -q analysis core creator llm longform multilingual plugins publish sdk server sources sports transcription video video_editor main.py	exit 0

The two messages quoted above are real output, from the same probe run against
main and against this branch with the platform downloader replaced by the
failure. No network request is made and no download happens in any test.

The new file follows the split already used in tests/test_input_safety.py: the
version lookup and the wording live in sources/ytdlp_common.py, which imports
without yt-dlp, so those run in the Python job. The four tests that need the
source modules sit behind pytest.importorskip("yt_dlp"), so they skip there and
run wherever yt-dlp is installed.

Anything reviewers should know

• This is option 1 of the three in Bundled yt-dlp goes stale between releases, so a site change breaks every install #39, not option 3. It says which yt-dlp
  produced the failure; the app still downloads and installs nothing, adds no
  startup check, and makes no request for a version. That is why it is Refs,
  not Fixes.
• The failure is preserved. The exception is re-raised, not replaced, so
  except DownloadError, except ValueError and except Exception all still
  catch it and the traceback still points at the platform that failed.
• Nothing is added where the app already explains itself. Every failure the
  sources translate into plain English raises ValueError (youtube._friendly_errors,
  kick._gone_or_raise: age-gated, deleted Kick VOD, live stream, wrong-platform
  link), and cancellations are left alone. Appending a version to those reads as
  noise, and on the live-stream and wrong-link ones it is not even relevant.
  The trade-off: if a future source explained a failure with something other
  than ValueError, that failure would get a version line it does not need.
• The signature lists are a heuristic, and they under-claim on purpose. An
  extractor error worded differently falls through to the version-only note
  rather than being guessed at. A test asserts that a timeout and both kinds of
  sign-in wall are not told to update.
• The note cannot leak anything. It interpolates the version and no part of
  the failure text, so it cannot put a cookie, token or private URL back into a
  message the job layer scrubs. There is a test for that.
• One limitation worth knowing: server/jobs.py broadcasts the first 500
  characters of a failure (2000 are stored). The note is appended, so a very
  long upstream error could push it out of the live event. Prefixing instead
  would cut the original reason, which seemed the worse trade.
• Not verified against a live site change. No real upstream break was
  reproduced; the classification is asserted against the wording yt-dlp is known
  to use, which models the failure rather than being it. Worth keeping in mind if
  a signature list needs widening later.
• Only failures reaching dispatch.download are annotated. Channel listing
  (sources/channel_feed.py) and the split-setup probe
  (sources/preview_frames.py) keep their current wording, since Bundled yt-dlp goes stale between releases, so a site change breaks every install #39 is about
  downloads — say the word if you want those covered too.

[vercel]

@chiragjangiir is attempting to deploy a commit to the Clips Studio Team on Vercel.

A member of the Team first needs to authorize it.

[ColinGPT9]

I will fix it in a couple of days