[Joloxx9]

Refs #857

Lets Youtarr download members-only videos when the account in the configured cookies is a member, while keeping today's behavior without cookies. It is built around the review points in #857 and on #851 (I've been running a simpler version of this in my own build and wanted the gaps you listed closed). Happy to fold this into #851 instead if @Agile86 is still working on it.

How it works

Access records (video_members_access, server/modules/membersAccess.js): one row per members-only video with access (confirmed/denied), cookie_key (SHA-256 of the cookie file) and checked_at.

• A verdict counts for 24 hours and only under the same cookie key. Replacing or editing the cookie file (external files included) retires every verdict without a write; settings saves and restarts keep them.
• The cookie key is computed once per request/run and memoized by path, size and mtime, never per row, and no Python process is started for it (external files go through readExternalCookies).

What counts as a denial: only a "Join this channel" refusal from a run where yt-dlp really got --cookies (spawnYtDlp reports cookiesPassed; preparation drops the flag for an unusable file), the file holds a live login cookie (cookieDetails), and no cookies are no longer valid / rotated warning was printed. Timeouts, bot checks, network errors, anonymous auto-retries, logged-out or expired files and rejected cookies record nothing about membership.

Ids: only [A-Za-z0-9_-]{11} ids are stored or put into the filter, and the filter checks again, since ids come from yt-dlp output an uploader can shape with a title.

Recovery: any successful yt-dlp read or download of a members-only video records confirmed, including after an earlier denial (validation, modal metadata fetch, downloads). A successful read showing another availability deletes the row and resets the channelvideos availability, so a video that went public stops reading as members-only.

Downloads

• No cookies: availability!=subscriber_only stays in every match filter, exactly as today.
• Cookies: scheduled channel sweeps add id!~='^(?:id1|id2)$' for fresh denials (your suggestion on feat: support members-only video downloads when cookies are enabled #851), so a denied video is skipped at the flat-listing stage without another request. Checked against yt-dlp 2026.10.26's match_filter_func.
• URL-list jobs never rely on that filter, because yt-dlp checks it on a video URL only after fetching it: playlist jobs (discoveries and retries) drop fresh denials before queuing, and Download All already did.
• Manual downloads clear the requested videos' verdicts and always ask again.
• External API requests keep availability!=subscriber_only, so an External API key never uses the owner's membership. Legacy API-key jobs behave like manual downloads.
• Download All's preview mirrors the same rule.

Listings and UI

• Channel and playlist listings return members_access (no_cookies | unchecked | confirmed | denied) for every video known to be members-only. A recorded check also covers videos from untracked channels on playlist pages.
• One selection rule (isMembersOnlyBlocked in videoStatus.tsx) and one chip (shared/MembersAccessChip) with the same colors on both pages. A local file, or its removal, takes priority over membership.
• The video modal checks access when it fetches metadata, offers Check access for an unchecked video (a cached .info.json is never re-fetched) and Check again for a denied one (POST /api/videos/:youtubeId/members-access/check, 10/min). A null answer means the video is no longer members-only. The channel and playlist pages both update the row from the modal's answer.
• Manual URL checks explain no cookies, no membership and unusable cookies separately; a members-only video the cookies can open gets the members chip in the list.
• Playlist listings stay anonymous; no change to playlist fetching or pruning.

Cookie settings text, docs/CONFIG.md, the playlist texts in the app and docs/USAGE_GUIDE.md / docs/YOUTARR_VS_ALTERNATIVES.md describe the behavior; Swagger covers the new fields on /getchannelvideos, /api/videos/{id}/metadata and /api/checkYoutubeVideoURL; docs/DATABASE.md, CLAUDE.md and the rule files are updated.

Testing

• Backend: 248 suites / 6929 tests pass. Frontend: 303 suites / 5631 tests pass. npm run lint and npm run lint:ts are clean.
• New tests: membersAccess.test.js (including the denied-list query: denied only, same cookie key, under 24 hours; crafted ids), membersAccessState.test.js (the real isBlockedState, shared by the Jest mock), scheduled channel runs passing the denial and no-cookies filters, playlist denial pre-filtering, External API jobs, cookiesPassed/usedCookies, the check route, validation/metadata/finalizer paths, listing fields, the members chip and checkbox in the card, list and table views, MembersAccessChip, useMembersAccessCheck, the modal check flow (including an inline parent callback that sets state) and the shared selection rule.
• Not run here: the migration against a real MariaDB (no Docker in my environment), and npm run docs:check (website deps not installed; no links were added).

🤖 Generated with Claude Code

[dialmaster]

Thanks for submitting this PR. You addressed a lot of the gaps from #851.

There are still some things to fix before this can go in. I left inline comments on each one.

A few things are in files the PR doesn't touch, so I couldn't comment on them inline:

• These still say members-only videos can't be downloaded:
  • client/src/components/PlaylistPage.tsx line 473
  • client/src/components/Subscriptions/PlaylistHelpDialog.tsx line 75
  • client/src/utils/playlistCounts.ts line 11
  • docs/USAGE_GUIDE.md line 214
  • docs/YOUTARR_VS_ALTERNATIVES.md line 94
• Swagger needs the new fields on /getchannelvideos, /api/videos/{id}/metadata and /api/checkYoutubeVideoURL.
• The playlist page doesn't pass onAvailabilityDetected, so a row doesn't update after a check in the modal.

Can you also add tests for these? Right now they could break without any test failing:

• the query behind the denied list (denied only, same cookie key, under 24 hours)
• scheduled channel runs passing the denial filter and the no-cookies filter to yt-dlp
• the real isBlockedState (the shared mock has its own copy)
• the members-only chip and checkbox in the channel views

[Joloxx9]

Thanks for the thorough review. Everything is in 02ff63b:

• Stale text: the PlaylistPage note, PlaylistHelpDialog, playlistCounts.ts, docs/USAGE_GUIDE.md and docs/YOUTARR_VS_ALTERNATIVES.md no longer say members-only videos cannot be downloaded.
• Swagger: members_access/availability on /getchannelvideos, membersAccess on /api/videos/{id}/metadata, and isMembersOnly/membersAccess/errorCode on /api/checkYoutubeVideoURL.
• Playlist page: now passes onAvailabilityDetected, so a row updates after a check in the modal (tested).
• Tests:
  • The denied-list query: denied only, same cookie key, cutoff at 24 hours.
  • Scheduled channel runs passing the denial filter and the no-cookies filter to getBaseCommandArgs.
  • The real isBlockedState, moved to membersAccessState.js, which the shared mock now imports instead of copying.
  • The members chip and checkbox in the card, list and table views.

Backend 6929 / frontend 5631 tests pass; lint and typecheck are clean.

[dialmaster]

Thanks for addressing my first review so quickly! I resolved all the existing comments, but when I re-reviewed I found a few more issues. See my new comments.

[Joloxx9]

Thanks for the second look! All three comments are addressed in 7a1763a, each with a test, and docs/CONFIG.md now covers the expired-cookies case. Ready for another review.

[dialmaster]

Thanks again for the additional changes. Everything I raised in the last round was addressed, but I thought about this a bit more and added a few more comments.

Also, a few comments for files that are not in the diff that need a line each:

• docs/EXTERNAL_API.md ("Create requests"): External API requests never use the owner's membership, so members-only videos are skipped. Only CONFIG.md says this right now
• docs/API_INTEGRATION.md (POST /api/videos/download): downloads with a legacy API key can now get members-only videos using the configured cookies. That's a change for anyone who has given out a key.

Can you add those too?

Once that's done... I think we've covered everything and this will be good to merge :)

[dialmaster]

This text now gives people a reason to use cookies from their real account, since that's usually the one with the membership. But YouTube can restrict or ban accounts that are used for automated downloads, and we don't say that anywhere here. The card right below says "use a throwaway account", but only because the file gives access to the account.

Can you add a sentence here saying that using a main account is at the user's own risk, with a link to the yt-dlp warning? https://github.com/yt-dlp/yt-dlp/wiki/Extractors#exporting-youtube-cookies

I think the same note should go in the "Members-Only Videos" section of docs/CONFIG.md, and the warning in CookieFileCard.tsx should mention the ban risk too so they all say the same thing.

[dialmaster]

I don't think this is right for rejected cookies. The file still has unexpired login cookies, so loginCookiesLive is true and the old filter is dropped. The refusal isn't saved as a denial either, and nothing remembers that the cookies were rejected. So each scheduled channel run tries the members-only videos again until the cookies are replaced.

It's the same loop as the expired cookies one, just a different way in. Can you either remember the rejection for that cookie key and keep availability!=subscriber_only while it stands, or change this sentence to match what happens?