YouTube's SABR-only streaming rollout produces errors like "Signature
solving failed" / "Requested format is not available" that don't
mention cookies, so the existing no-cookies fallback never triggered.
Cookies also disable the android client, which is often the only one
still returning usable formats under this restriction.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Remove get_cookies.sh (targets a container without yt-dlp, already
broken), get_cookies_local.sh, start_all.sh/stop_all.sh — these
implement the old per-service-compose startup that now conflicts
with the unified root docker-compose.yml.
- Add cookies-cron/ — a reference copy of the scripts actually running
via cron on the separate browser-equipped machine, with setup
requirements and instructions for standing up a new cron host.
- Update README.md/ARCHITECTURE.md to describe the current unified
docker-compose + CI/CD deploy flow and host-mounted cookies instead
of the old per-folder workflow.
Cookies baked into the image (COPY . .) required a full CI/CD rebuild
to refresh, incompatible with the cron job on the fedora machine that
re-extracts cookies from a logged-in browser every 20 minutes and
scp's them to prod. Volume-mount the cookies file instead — yt-dlp
reads it from disk per request, so a fresh scp takes effect
immediately with no container restart. The image-baked copy still
exists as a build-time fallback.
Also refresh the committed cookies snapshot (the cron's source yt-dlp
turned out to be missing on the fedora box, so prior commits had been
carrying years-stale cookies without anyone noticing).
EXTRACTOR_ARGS used ':' instead of ';' between player_client and skip
fields, so yt-dlp parsed "android:skip=translated_subs" and "hls" as
bogus player_client values and silently fell back to the web client
only, which fails the n-challenge and returns no formats.
--max-requests=1 fully restarted the gunicorn worker after every
single request, opening a race window that could drop the response
connection right after a successful download; raised to 20 with
jitter to keep the periodic-recycle safety net without doing it on
every request.
reply_video() to Telegram had no retry, so a transient httpx
transport error during upload discarded an already-downloaded video;
added the same 3-attempt retry pattern already used for the
downloader services.
- Замена reply_video() на reply_document() в bot.py — Telegram больше не сжимает видео
- Исправление format_id в get_youtube_formats(): конкретные format codes + fallback best[height<=N]
- Замена bestvideo[height<=N]+bestaudio на best[height<=N] — гарантированно работает когда
YouTube не отдаёт отдельные video-only потоки для низких разрешений
- Добавлено логирование реально скачанного формата для диагностики
- Разделение на микросервисы: youtube-downloader, instagram-downloader, vk-downloader
- Основной бот в корне проекта, работает через HTTP API с сервисами
- Каждый сервис запускается отдельно в своей папке
- Видео сохраняются в папке video/ и не удаляются
- Обновлена документация и архитектура
- Скрипты для Instagram cookies перенесены в instagram-downloader/
