Retry "Video unavailable" downloads without cookies when anonymous extraction succeeds

[JT4G]

Description

Youtarr can fail to download certain publicly available YouTube videos when cookies are enabled.

yt-dlp reports:

ERROR: [youtube] <video-id>: Video unavailable

However, the exact same video succeeds when yt-dlp is run without cookies.

I have seen this affect multiple videos from the same channel repeatedly over more than a week.

Youtarr currently retries the affected video on subsequent channel scans using cookies again, so it keeps failing with the same error.

Environment

• Youtarr: v1.81.1
• yt-dlp: stable@2026.08.19
• Python: 3.11.2
• ffmpeg: 5.1.9
• Docker on Linux
• Cookies enabled using Youtarr's uploaded cookie file
• yt-dlp IP family: IPv4

Reproduction

Affected video:

https://www.youtube.com/watch?v=kLibHr-jNeE

Without cookies:

docker exec -it youtarr yt-dlp -vU --simulate \
  "https://www.youtube.com/watch?v=kLibHr-jNeE"

This succeeds:

[youtube] kLibHr-jNeE: Downloading visionos player API JSON
[info] kLibHr-jNeE: Downloading 1 format(s): 401+251-5

With cookies:

docker exec -it youtarr yt-dlp -vU --simulate \
  --cookies /app/config/cookies.user.txt \
  "https://www.youtube.com/watch?v=kLibHr-jNeE"

This fails:

[debug] [youtube] Found YouTube account cookies
[debug] [youtube] kLibHr-jNeE: web_embedded player response playability status: UNPLAYABLE
[debug] [youtube] kLibHr-jNeE: tv_downgraded player response playability status: UNPLAYABLE
ERROR: [youtube] kLibHr-jNeE: Video unavailable

Forcing tv_downgraded with cookies also fails:

--extractor-args "youtube:player_client=tv_downgraded"

visionos cannot be used while cookies are enabled:

WARNING: [youtube] Skipping client "visionos" since it does not support cookies

But adding --no-cookies after the cookie option succeeds:

docker exec -it youtarr yt-dlp -vU --simulate \
  --cookies /app/config/cookies.user.txt \
  --no-cookies \
  "https://www.youtube.com/watch?v=kLibHr-jNeE"

Result:

[youtube] kLibHr-jNeE: Downloading visionos player API JSON
[info] kLibHr-jNeE: Downloading 1 format(s): 401+251-5

Working proof-of-concept

I patched Youtarr locally using its existing auto-retry system.

The logic is:

1. Normal download runs with cookies.
2. An individual video fails with Video unavailable.
3. If cookies are enabled, Youtarr marks that failed video for an anonymous retry.
4. Only that video is queued again.
5. The retry adds --no-cookies.
6. yt-dlp uses the visionos client.
7. The download succeeds.

This was tested during an actual scheduled Youtarr channel download.

The logs showed:

ERROR: [youtube] kLibHr-jNeE: Video unavailable

Then:

"anonymousRetry":true

Then:

Retrying cookie-specific Video unavailable failure without cookies

The retry yt-dlp arguments contained:

--cookies /app/config/cookies.user.txt
...
--no-cookies
https://www.youtube.com/watch?v=kLibHr-jNeE

Then:

[youtube] kLibHr-jNeE: Downloading visionos player API JSON
[info] kLibHr-jNeE: Downloading 1 format(s): 299+140-5

and the video downloaded successfully.

Proposed behaviour

When:

• cookies are enabled
• an individual video fails with Video unavailable
• the video is not members-only, upcoming, a premiere, terminated, etc.

Youtarr should retry only that failed video once without cookies.

Cookies should not be disabled globally because they are still needed for other videos and YouTube bot checks.

Implementation notes

Youtarr already has most of the required infrastructure through:

• transient403RetryPlanner.js
• downloadJobFinalizer.js
• enqueueAutoRetryJob()
• doSpecificDownloads()

The working local patch:

• detects cookie-specific Video unavailable
• carries an anonymousRetry flag
• separates normal authenticated retries from anonymous retries
• appends --no-cookies only to the anonymous retry job
• keeps normal 403 retries authenticated
• continues to use the existing retry-attempt limit

Additional affected video

I have also seen repeated Video unavailable failures with:

JWQYT7m6P-M

So this appears to affect multiple videos, not just one.

Expected result

Youtarr should continue using cookies normally, but automatically fall back to an anonymous retry for an individual public video when authenticated extraction incorrectly returns Video unavailable.

[JT4G]

I also generated the exact diff from the working local patch that successfully recovered the affected video during a scheduled Youtarr run.

The patch reuses Youtarr's existing auto-retry flow rather than adding a separate retry mechanism.

1. transient403RetryPlanner.js

--- /app/server/modules/download/transient403RetryPlanner.js.bak-cookie-fallback
+++ /app/server/modules/download/transient403RetryPlanner.js
@@ -12,6 +12,12 @@

 const HTTP_403_PATTERN = /http error 403|403[:\s]+forbidden/i;

+// Some videos can return "Video unavailable" only when authenticated
+// cookies are used, while anonymous extraction succeeds through a different
+// YouTube client. These are eligible for an anonymous retry.
+const COOKIE_VIDEO_UNAVAILABLE_PATTERN =
+  /^\s*(?:\[youtube\]\s+[^:]+:\s*)?Video unavailable\s*$/i;
+
 // Fragment-based 403 failures surface the 403 only in WARNING lines; the final
 // ERROR line just reports the data/fragment failure. When the run-level 403
 // flag is set, treat these error shapes as 403-caused.
@@ -54,6 +60,16 @@
   return false;
 }

+function isCookieVideoUnavailableFailure(
+  failedVideo,
+  { cookiesEnabled = false } = {}
+) {
+  if (!cookiesEnabled) return false;
+
+  const error = String((failedVideo && failedVideo.error) || '');
+  return COOKIE_VIDEO_UNAVAILABLE_PATTERN.test(error);
+}
+
 // Decides whether (and for which videos) to enqueue an auto-retry job.
 // botDetected means a retry can't help (cookies are required); sourceJobData
 // carries the attempt counter. Returns { retryVideos, nextAttempt } or null.
@@ -64,6 +80,7 @@
   wasTerminated = false,
   sourceJobData = {},
   maxAttempts,
+  cookiesEnabled = false,
 } = {}) {
   if (botDetected || wasTerminated) return null;
   if (!Array.isArray(failedVideosList) || failedVideosList.length === 0) return null;
@@ -74,13 +91,24 @@

   const retryVideos = failedVideosList
     .filter((video) => video && video.youtubeId)
-    .filter((video) => isTransient403Failure(video, { httpForbiddenDetected }))
-    .map((video) => ({
-      youtubeId: video.youtubeId,
-      // Channel-sweep failures never enter the archive diff, so their url is
-      // usually null; reconstruct it from the youtube id.
-      url: video.url || `https://www.youtube.com/watch?v=${video.youtubeId}`,
-    }));
+    .filter((video) =>
+      isTransient403Failure(video, { httpForbiddenDetected }) ||
+      isCookieVideoUnavailableFailure(video, { cookiesEnabled })
+    )
+    .map((video) => {
+      const anonymousRetry = isCookieVideoUnavailableFailure(
+        video,
+        { cookiesEnabled }
+      );
+
+      return {
+        youtubeId: video.youtubeId,
+        // Channel-sweep failures never enter the archive diff, so their url is
+        // usually null; reconstruct it from the youtube id.
+        url: video.url || `https://www.youtube.com/watch?v=${video.youtubeId}`,
+        anonymousRetry,
+      };
+    });

   if (retryVideos.length === 0) return null;

@@ -90,6 +118,7 @@
 module.exports = {
   planAutoRetry,
   isTransient403Failure,
+  isCookieVideoUnavailableFailure,
   resolveRetryCount,
   MAX_AUTO_RETRY_COUNT,
   DEFAULT_AUTO_RETRY_COUNT,

2. downloadJobFinalizer.js

--- /app/server/modules/download/downloadJobFinalizer.js.bak-cookie-fallback
+++ /app/server/modules/download/downloadJobFinalizer.js
@@ -210,6 +210,7 @@
         wasTerminated,
         sourceJobData,
         maxAttempts: configModule.getConfig().downloadAutoRetryCount,
+        cookiesEnabled: Boolean(configModule.getCookiesPath()),
       });
       if (retryPlan) {
         try {

3. downloadModule.js

--- /app/server/modules/downloadModule.js.bak-cookie-fallback
+++ /app/server/modules/downloadModule.js
@@ -117,6 +117,34 @@
   async enqueueAutoRetryJob({ retryVideos, autoRetryAttempt, runId, sourceJobData = {} }) {
     if (!Array.isArray(retryVideos) || retryVideos.length === 0) return;

+    // Keep normal transient-403 retries authenticated, while videos that
+    // specifically failed with cookie-induced "Video unavailable" are retried
+    // anonymously. Never mix the two modes in one yt-dlp invocation.
+    const anonymousVideos = retryVideos.filter(
+      (video) => video && video.anonymousRetry === true
+    );
+    const authenticatedVideos = retryVideos.filter(
+      (video) => !video || video.anonymousRetry !== true
+    );
+
+    if (anonymousVideos.length > 0 && authenticatedVideos.length > 0) {
+      await this.enqueueAutoRetryJob({
+        retryVideos: authenticatedVideos,
+        autoRetryAttempt,
+        runId,
+        sourceJobData,
+      });
+
+      await this.enqueueAutoRetryJob({
+        retryVideos: anonymousVideos,
+        autoRetryAttempt,
+        runId,
+        sourceJobData,
+      });
+
+      return;
+    }
+
     const ownerChannelMap = { ...(this.getJobDataValue(sourceJobData, 'ownerChannelMap') || {}) };
     const unmappedIds = retryVideos
       .map((video) => video.youtubeId)
@@ -151,6 +179,9 @@
       overrideSettings: { ...this.getOverrideSettings(sourceJobData) },
       jobLabel: autoRetryJobLabel(retryVideos.length),
       autoRetryAttempt,
+      anonymousRetry: retryVideos.every(
+        (video) => video && video.anonymousRetry === true
+      ),
     };
     if (Object.keys(ownerChannelMap).length > 0) body.ownerChannelMap = ownerChannelMap;
     if (channelId) body.channelId = channelId;
@@ -713,6 +744,17 @@
         // Pass audioFormat for MP3 downloads
         const args = YtdlpCommandBuilder.getBaseCommandArgsForManualDownload(resolution, allowRedownload, audioFormat, skipVideoFolder);

+        // A targeted anonymous auto-retry overrides Youtarr's managed
+        // --cookies argument. yt-dlp processes these options in order, so the
+        // later --no-cookies wins while normal downloads still use cookies.
+        if (this.getJobDataValue(jobData, 'anonymousRetry')) {
+          args.push('--no-cookies');
+          logger.info(
+            { urls },
+            'Retrying cookie-specific Video unavailable failure without cookies'
+          );
+        }
+
         // Check if any URLs are for videos marked as ignored, and remove them from archive
         // This allows users to manually download videos they've marked to ignore for channel downloads
         if (!allowRedownload) {

Successful runtime test

This exact patch was tested during a real scheduled Youtarr channel download.

The initial authenticated attempt failed:

ERROR: [youtube] kLibHr-jNeE: Video unavailable

Youtarr then created the targeted retry with:

anonymousRetry: true

The patched retry path logged:

Retrying cookie-specific Video unavailable failure without cookies

The retry's yt-dlp arguments contained the normal managed cookie argument followed later by the override:

--cookies /app/config/cookies.user.txt
...
--no-cookies
https://www.youtube.com/watch?v=kLibHr-jNeE

yt-dlp was then able to use the visionos client:

[youtube] kLibHr-jNeE: Downloading visionos player API JSON
[info] kLibHr-jNeE: Downloading 1 format(s): 299+140-5

The video downloaded successfully and Youtarr recorded the auto-retry job as Complete.

This means the tested flow was:

Normal Youtarr download with cookies
        ↓
Video unavailable
        ↓
Targeted auto-retry
        ↓
--no-cookies
        ↓
visionos extraction
        ↓
Successful download

Normal downloads and existing transient HTTP 403 retries continue using cookies.

Small UI consideration

Because the proof-of-concept reuses the existing transient 403 retry infrastructure, the successful retry currently appears in Download History as:

Auto-retry: 1 video (HTTP 403)

even though this particular retry was caused by the cookie-specific Video unavailable fallback.

If this is implemented upstream, a more accurate label for this retry type might be something like:

Auto-retry: 1 video (cookie fallback)

The label issue is cosmetic only; the fallback itself is working successfully.

[BigFlubba]

Submit a PR.

I've noticed this too with quite a few videos. I opened the video in a browser that is logged into the same account I use for cookies, and I cannot play the videos officially. I can, however, play the videos on my main account that are blocked on my burner. I do not know if this is an age restriction or if Google is trying to block my account.

This also plays into #774

[JT4G]

Thanks, that sounds like exactly the same behaviour I'm seeing.

I tested this further and confirmed that the failure is specifically tied to the authenticated/cookie attempt.

For an affected public video, Youtarr/yt-dlp using my configured cookies returned:

Video unavailable

The same video was accessible anonymously.

I've now tested a local Youtarr patch which handles this by:

• keeping cookies enabled for normal downloads
• detecting an authenticated Video unavailable failure
• marking only that failed video for an anonymous retry
• retrying it with --no-cookies
• leaving the existing authenticated 403 retry behaviour unchanged
• keeping the existing auto-retry attempt limit

The important part is that it does not disable cookies globally. It only falls back to an anonymous retry for the individual video that failed while authenticated.

I've now had this happen in a real scheduled channel download and the patched behaviour worked as intended:

1. Authenticated download returned Video unavailable
2. Youtarr automatically queued the affected video for an anonymous retry
3. The anonymous retry successfully downloaded the video
4. The retry was recorded as Auto-retry — Complete

I've also seen the same Video unavailable behaviour repeatedly with another video/channel, so it doesn't appear to be isolated to one video.

I'll look at submitting the working implementation as a PR.

[BigFlubba]

While I do like this option. I think implementing #774 first, then adding the option to have "Video unavailable" errors added to the list of errors that bypass cookies, would be a better option. This way, the codebase doesn't need to be rewritten twice for both options.

EDIT:

Regarding the other comment about #774, I don't think we need to block on it. #774 is basically the mirror image (anonymous first, cookies on failure), and the plumbing here is what it'd reuse with the flag flipped.

I like that wording better than what I had in my head. Even though it will take a little longer, it is still a better approach if the user opts into it because (combined with a VPN that has a shared IP) it reduces what Google knows about you specifically and the chance of getting blocked. PO support will also add to that because, even with cookies, I am getting limited and blocked in some areas. Gotta love it.

[dialmaster]

#827 has been merged to dev and will go out with the next release.