7a90b008f0
ditch the per-run batch cap (a 200-video backlog would've taken weeks). now the 'Download YouTube Wishlist' automation queues the ENTIRE wishlist as 'queued' rows, starts up to max_concurrent (default 3) right away, and each finished download starts the next (one-out-one-in in the worker) so it all drains in a controlled stream. the knob is 'max simultaneous downloads', not a total cap. mirrors the music download worker's lesson (cap concurrency + space starts to avoid yt-dlp 429s) but stays isolated on the video side: - youtube_download: _pace() staggers fetch starts (3s); start_next_queued() claims+spawns the next; run_youtube_download chains on finish. - db.count_active_youtube_downloads() + claim_next_youtube_queued() (atomic, race-safe). block field batch_size -> max_concurrent. all seam-tested (pure select + pump); 680-test sweep green. |
||
|---|---|---|
| .. | ||
| handlers | ||
| __init__.py | ||
| api.py | ||
| blocks.py | ||
| deps.py | ||
| progress.py | ||
| schedule.py | ||
| signals.py | ||