What causes "Timeout fetching playlist (120s)" in tonhowtf/omniget?

Split very large playlists into chunks and fetch them in batches under 120s each

Timeout fetching playlist (120s)

Error message

Timeout fetching playlist (120s)

What it means

In get_playlist_info, the yt-dlp `.output()` call is wrapped in tokio::time::timeout with a fixed 120-second budget; if the playlist fetch exceeds it, the future is dropped and this error returned. Playlist enumeration (many entries) is much slower than single-video info, so this cap is easier to hit.

Solutions

Split very large playlists into chunks and fetch them in batches under 120s each
Ensure yt-dlp is up to date and uses fast flat extraction (e.g. --flat-playlist) for listing
Check for 429 rate limiting (the code tracks it) and back off / use cookies if needed
Increase the timeout for large playlists or make it proportional to expected entry count

Defensive patterns

Strategy: retry

Validate before calling

// Estimate playlist size first with a short flat probe before the full fetch
let probe = tokio::time::timeout(
    std::time::Duration::from_secs(30),
    ytdlp_command(ytdlp).args(["--flat-playlist", "--playlist-items", "1", "--dump-json", url]).output(),
).await;
if probe.is_err() { return Err("playlist source too slow; check network or split playlist".into()); }

Try / catch

match get_playlist_info(url).await {
    Err(e) if e.to_string().contains("Timeout fetching playlist") => {
        // retry with chunked fetching or a larger budget
    }
    other => other,
}

Prevention

Use --flat-playlist for listing to avoid per-video extraction cost
Scale the timeout with playlist size instead of a fixed 120s
Respect 429 backoff signals before retrying so yt-dlp does not stall internally
Warn users that very large playlists may need chunked fetching

When it happens

Trigger: Calling get_playlist_info on a large playlist (hundreds of entries) where yt-dlp's flat extraction exceeds 120s; slow network to the hosting site; yt-dlp hanging on rate limiting or bot-check pages.

Common situations: Very large YouTube playlists on throttled connections; sites requiring slow challenge solving; proxy latency; 429 rate-limiting causing yt-dlp to back off past the timeout.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of tonhowtf/omniget@8600b91f42 (2026-09-12). Data as JSON: /api/errors/88ce48d5e4d2ff63. Report an issue: GitHub.

Appendix: source

Thrown at src-tauri/omniget-core/src/core/ytdlp.rs:2586

    }

    append_metadata_cookie_args(&mut args, url, extra_flags, "playlist info");

    args.extend(proxy_args());
    args.extend(extra_flags.iter().cloned());
    args.push(url.to_string());

    let _slot = acquire_ytdlp_slot("playlist info").await;
    let output = tokio::time::timeout(
        std::time::Duration::from_secs(120),
        ytdlp_command(ytdlp)
            .args(&args)
            .stdout(Stdio::piped())
            .stderr(Stdio::piped())
            .output(),
    )
    .await
    .map_err(|_| anyhow!("Timeout fetching playlist (120s)"))?
    .map_err(|e| anyhow!("Failed to run yt-dlp: {}", e))?;

    if !output.status.success() {
        let stderr = String::from_utf8_lossy(&output.stderr);
        let stderr_lower = stderr.to_lowercase();
        if stderr_lower.contains("http error 429") {
            rate_limit_429_increment();
            let sanitized_url = sanitize_log_line(url);
            let player_client = if is_youtube_url(url) {
                "default"
            } else {
                "n/a"
            };
            tracing::warn!(
                "[yt-429] rate limit in get_playlist_info: url={} player_client={} retries=3",
                sanitized_url,
                player_client
            );

View on GitHub (pinned to 8600b91f42)