feat: keep yt-dlp current, harden downloads, fix notification & photo handling#206
Merged
Conversation
The yt-dlp provider binary lives in a persistent volume and was only ever downloaded once, so it froze at whatever version was first installed and Instagram extraction broke as the site changed. Keep it fresh and resilient: - Track the nightly release channel (extractor fixes land there first) and self-update the binary on boot (if stale) and weekly via the scheduler. - Add YTDLP_COOKIES_FILE support so login-gated / audience-restricted posts download with an authenticated session (--cookies on all yt-dlp calls). - Modern format selection (bv*+ba/b) so split-DASH sources (Instagram) merge correctly, plus retry parity for video downloads (matching audio). - Surface the installed version + staleness in /api/health and the provider list so a frozen binary is visible instead of silently rotting. - Move the pure version/caption helpers into a leaf module to break the provider/registry import cycle; unit-tested in isolation.
Two download-pipeline corrections:
- The group was notified on every download outcome, including failures ("Still
notify — viewable via external link"), so a failed clip pushed a false "X
added a video". Notify only when a clip reaches genuine ready (uploaded and
viewable); setClipReady's ready branch and publishQueuedClip already do this.
- Scrolly is video-only, but photo/carousel shares were left as opaque failures.
Detect yt-dlp's confirmed no-video signature and reject with a clear reason
("Not a video — Scrolly only supports video posts"). No notification.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Instagram video downloads were failing group-wide. Root cause: the yt-dlp provider binary lives in a persistent volume and was only ever downloaded once, so it froze at
2026.02.21while Instagram changed its internals. On top of that, failed downloads were pushing false "X added a video" notifications, and photo posts (Scrolly is video-only) were left as opaque failures.What
Keep yt-dlp current + hardened (
a2bc3c8)YTDLP_COOKIES_FILEso login-gated / audience-restricted Instagram posts download with an authenticated session (--cookieson all yt-dlp calls).bv*+ba/b) so split-DASH sources (Instagram) merge correctly, plus retry parity for video downloads (matching audio)./api/healthand the provider list, so a frozen binary is visible instead of silently rotting.Download-pipeline fixes (
3e759b2)ready— failures/queued/no-provider/size-reject no longer push a false "added a video".Test plan
npm run check— cleannpm test— 529/529 passing (addsytdlpversion-helper tests +download-notifynotification/rejection tests)npm run build— succeeds (adapter-node)