jamesandClaude Opus 5
0a9af17246
Every YouTube download — /force and the normal clip path alike — was failing at the data-transfer stage with "HTTP Error 403: Forbidden". Extraction succeeded and a format was selected; only the media fetch died, which is why it read as a per-video problem rather than a broken extractor. The cause was YouTube retiring the cookieless `android_vr` client that yt-dlp 2026.6.9 pinned. Its media URLs now 403 for every video, so the failure was global rather than specific to the video that surfaced it. 2026.8.19 re-points at `visionos` and downloads work again. Refresh the cookie-withholding note, which named android_vr as the client whose URLs work, and record the 403-on-data-transfer signature as the tell for a retired client so the next occurrence goes straight to a yt-dlp upgrade instead of the cookie or format logic. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QH4jMHfUTDhm41BrRtkPc3
10 lines
504 B
Plaintext
10 lines
504 B
Plaintext
signalbot==1.1.0
|
|
# yt-dlp is kept current for site/extractor changes; bump the floor deliberately.
|
|
# 2026.8.19 restores YouTube downloads: the cookieless client the older build
|
|
# pinned (android_vr) was retired and every data transfer 403'd.
|
|
yt-dlp>=2026.8.19
|
|
# Needed for YouTube: yt-dlp wraps URLs in a JS "n-sig" challenge that a JS
|
|
# runtime must solve. Requires Node >= 22 on PATH (bot.py points at a standalone
|
|
# /opt/node22 since Debian 13 only ships Node 20) plus this package.
|
|
yt-dlp-ejs>=0.8.0
|