Resolving a URL to a job id cost a metadata request on every invocation,
including re-runs with nothing to do. index.json records what the last
expansion produced and a single-video URL is now answered from it: measured on
a finished job, 2.25s and three requests becomes 0.75s and none, and the resume
succeeds with the network blocked entirely, where it previously failed.
A playlist is deliberately still re-read. Answering one from the index would
silently ignore videos added to it since the last run, and that request is the
only way to notice them. Entries are keyed by whether --playlist was in effect,
because the same URL names a different set with and without it.
When a URL that has been expanded before can no longer be read, the recorded
jobs are used and the reason is logged rather than failing the whole URL. This
keys on the source being unreadable rather than on a particular error, because
an unreachable host surfaces as "no metadata" -- yt-dlp reports the failure and
returns nothing rather than raising. Only a previously expanded URL can reach
this, so it cannot invent work, and any job still needing a download fails on
its own merits. That NotFoundError's hint no longer claims a bad URL is the
only explanation.
Target replaces the (url, entry) tuple so a job id survives without metadata,
and store grows the atomic JSON write that save and the index now share.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
JMR-devandClaude Opus 5
1114595de7