4b15d55092
Root cause of the failing downloads: containers usually have no working IPv6 route, but googlevideo CDN hosts advertise AAAA records, so the downloader tried IPv6 and failed with '[Errno -5] No address associated with hostname'. Small clips happened to use IPv4; long videos (more CDN requests / the ffmpeg path) hit IPv6 and died. - yt-dlp source_address=0.0.0.0 forces IPv4 for every connection (== --force-ipv4). Verified: the full video+audio download completes cleanly. - Also: retry (resume) now resets the shared asset from 'error' to 'pending', so it actually re-downloads — previously the requeued job instantly re-inherited the asset's stale error because the worker short-circuits a job whose asset already errored. - Dropped the localdev DNS override (wrong hypothesis; the issue was IPv6, not the resolver). - Kept yt-dlp retries/fragment_retries/socket_timeout for transient blips. Verified end-to-end in the worker: two previously-failing long videos now download to done. |
||
|---|---|---|
| .. | ||
| alembic | ||
| app | ||
| alembic.ini | ||
| Dockerfile | ||
| entrypoint.sh | ||
| log_config.json | ||
| requirements.txt | ||