If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/nilaoda/N_m3u8DL-CLI shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 3y ago

• 8 active contributors
• MIT licensed
• CI configured
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 92% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live nilaoda/N_m3u8DL-CLI repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/nilaoda/N_m3u8DL-CLI.

What it runs against: a local clone of nilaoda/N_m3u8DL-CLI — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in nilaoda/N_m3u8DL-CLI | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 1101 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of nilaoda/N_m3u8DL-CLI. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/nilaoda/N_m3u8DL-CLI.git
#   cd N_m3u8DL-CLI
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of nilaoda/N_m3u8DL-CLI and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "nilaoda/N_m3u8DL-CLI(\\.git)?\\b" \\
  && ok "origin remote is nilaoda/N_m3u8DL-CLI" \\
  || miss "origin remote is not nilaoda/N_m3u8DL-CLI (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1101 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1071d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/nilaoda/N_m3u8DL-CLI"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

N_m3u8DL-CLI is a .NET Framework command-line downloader for HLS/m3u8/DASH video streams that downloads and converts them to MP4 or TS format. It supports AES-128-CBC decryption, multi-threaded downloading, live stream recording, custom HTTP headers, and automatic merging using FFmpeg or binary concatenation. The project is in maintenance mode since the author recommends N_m3u8DL-RE for cross-platform support. Single monolithic .NET Framework application in N_m3u8DL-CLI/ directory with specialized decoder modules (Decode51CtoKey.cs, DecodeDdyun.cs, etc.) for platform-specific encryption, a core Downloader.cs and DownloadManager.cs for orchestration, Parser.cs and MPDParser.cs for manifest parsing, and Decrypter.cs for AES-128-CBC. Localization via .resx files (English, Simplified Chinese, Traditional Chinese).

Video content creators, streaming enthusiasts, and security researchers on Windows who need to archive HLS streams from educational platforms, video services, and live broadcasts. Users who require automation and fine-grained control over download parameters (thread counts, retry logic, bandwidth limiting, time-range selection).

Mature but dormant: ~2.8k GitHub stars, open-sourced in October 2019 under MIT license, with active CI/CD via GitHub Actions (build_latest.yml workflow), but the README explicitly states the project entered 'maintenance mode' with cross-platform development moved to N_m3u8DL-RE. Commit recency data not provided, but the changelog and documentation are comprehensive.

Moderate risk: single maintainer (nilaoda), tied to .NET Framework which limits OS support, and the active development has moved to a separate Rust-based successor (N_m3u8DL-RE). Dependency risk is mitigated by straightforward .NET Framework dependencies listed in packages.config. No visible test suite in file structure suggests limited regression protection.

The project is in maintenance mode with no active feature development visible. The README directs new users to N_m3u8DL-RE for ongoing improvements. Build automation via GitHub Actions suggests security patches and minor fixes may still occur, but the codebase is essentially stable.

Clone the repo, open N_m3u8DL-CLI.sln in Visual Studio, and build the project targeting .NET Framework (via packages.config dependencies). The compiled executable runs from command line: N_m3u8DL-CLI.exe <URL> [OPTIONS] — no npm/dotnet restore required beyond VS default NuGet restoration.

Daily commands: Build in Visual Studio or via command line: msbuild N_m3u8DL-CLI.sln. Run: N_m3u8DL-CLI.exe <m3u8_url_or_file> --saveName output --maxThreads 16. Pre-built binaries available at https://github.com/nilaoda/N_m3u8DL-CLI/releases. Optional: place FFmpeg.exe in same directory for advanced muxing.

• N_m3u8DL-CLI/Program.cs: Entry point and command-line argument routing; defines how user input flows to downloader components.
• N_m3u8DL-CLI/Downloader.cs: Core download orchestration logic; manages multi-threaded segment fetching, retry, and progress tracking.
• N_m3u8DL-CLI/Parser.cs: Parses m3u8 manifest files and extracts segment URLs, encryption keys, and stream metadata.
• N_m3u8DL-CLI/Decrypter.cs: Handles AES-128-CBC decryption of encrypted segments using keys extracted from manifests.
• N_m3u8DL-CLI/MPDParser.cs: Parses DASH/MPD manifest format as alternative to m3u8, enabling DASH stream downloads.
• N_m3u8DL-CLI/DownloadManager.cs: Manages thread pool, queue, and concurrent segment downloads with rate limiting and timeout enforcement.
• N_m3u8DL-CLI/FFmpeg.cs: Wraps FFmpeg binary for muxing downloaded segments into MP4 or audio-only output.
• N_m3u8DL-CLI/Global.cs: Global configuration state and utility functions shared across modules.

For decryption logic: edit Decrypter.cs and platform-specific Decode*.cs files (e.g., DecodeDdyun.cs for Ddyun platform). For parsing: modify Parser.cs (m3u8) or MPDParser.cs (DASH). For download behavior: edit Downloader.cs and DownloadManager.cs. For CLI options: update MyOptions.cs and Program.cs argument handling. Localization strings in strings.resx (Chinese, English variants).

FFmpeg.exe must be in the same directory or in PATH for --muxSetJson and automatic merging; if missing, binary concatenation fallback may produce invalid output. The --headers format uses pipe (|) as delimiter between key:value pairs, which is non-standard and easy to get wrong. Platform-specific decoders (Decode51CtoKey.cs, DecodeCdeledu.cs, etc.) are hardcoded for specific Chinese streaming services and will silently fail on unsupported platforms. .NET Framework 4.x is Windows-only; no cross-platform support. Live stream recording (HLSLiveDownloader.cs, Watcher.cs) is marked BETA and may have stability issues. The project uses system proxy settings by default (can be disabled); misconfigured proxies will cause silent download failures.

• HLS (HTTP Live Streaming) and m3u8 manifests — Understanding the m3u8 playlist format (segments, encryption keys, variant streams, media types) is essential to understanding what Parser.cs extracts and why Downloader.cs fetches in sequence.
• AES-128-CBC block cipher encryption — The Decrypter.cs module implements AES-128-CBC decryption of HLS segments; understanding cipher block chaining, IV (initialization vector) handling, and key derivation is needed to modify or fix decryption logic.
• DASH (Dynamic Adaptive Streaming over HTTP) and MPD manifests — MPDParser.cs handles DASH manifests as an alternative to m3u8; DASH uses XML instead of plaintext and introduces additional complexity like period/adaptation-set/representation hierarchy that affects download logic.
• Thread pooling and concurrent download orchestration — DownloadManager.cs uses .NET ThreadPool and manual thread management to balance minThreads/maxThreads for multi-threaded segment downloads; understanding thread-safety, queue signaling, and timeout is critical for modifying download behavior.
• Master playlists (variant streams) — HLS supports Master playlists that list multiple quality variants; Parser.cs must detect and choose a variant before downloading segments, affecting the entire download flow.
• Binary segment concatenation vs. muxing — DownloadManager and FFmpeg.cs implement two merging strategies: raw binary concat (fast, works for .ts) and FFmpeg muxing (slow, required for .mp4 with proper container headers); choosing the right strategy affects output validity.
• Retry strategies and exponential backoff — Downloader.cs uses --retryCount parameter for resilience; understanding retry logic, timeout handling, and failure classification helps debug flaky downloads or network issues.

• nilaoda/N_m3u8DL-RE — Official successor to this project; rewritten in Rust with cross-platform support (Win/Linux/Mac) and active development. Users should migrate here for ongoing feature work.
• lycheeorg/lychee — Not directly related but shares CLI philosophy for media batch processing; useful reference for argument parsing patterns in .NET.
• yt-dlp/yt-dlp — Industry-standard media downloader (Python) that inspired m3u8 download CLI patterns; useful for comparing feature parity and UX decisions in alternative ecosystems.
• grafov/m3u8 — Go library for parsing m3u8 manifests; reference implementation for m3u8 spec compliance if you need to compare parsing logic.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for decryption modules (CSChaCha20.cs, Decrypter.cs, and platform-specific decoders)

The repo contains multiple specialized decryption implementations (CSChaCha20.cs, Decrypter.cs, Decode51CtoKey.cs, DecodeCdeledu.cs, DecodeDdyun.cs, DecodeHuke88Key.cs, DecodeImooc.cs, DecodeNfmovies.cs) but no visible test files in the structure. These are security-critical components that handle decryption logic for various platforms. Adding unit tests would catch regressions, validate edge cases, and make it safer for contributors to refactor these modules.

• [ ] Create a new Test project N_m3u8DL-CLI.Tests alongside the main project
• [ ] Add unit tests for Decrypter.cs covering AES-128-CBC decryption with known test vectors
• [ ] Add tests for CSChaCha20.cs with sample ciphertexts and expected plaintexts
• [ ] Add tests for each platform-specific decoder (Decode*.cs) with mock data from their respective services
• [ ] Configure test runner in GitHub Actions (build_latest.yml) to run tests on every push

Extract duplicate HTTP client and request header logic from Downloader.cs and HLSLiveDownloader.cs into a shared HttpClientManager.cs

Both Downloader.cs and HLSLiveDownloader.cs likely manage HTTP requests with custom headers. The repo supports 'custom request headers' as a feature but this logic may be duplicated across these two files. Creating a centralized HttpClientManager would reduce code duplication, make header management consistent, and simplify maintenance when adding new features like proxy support or retry policies.

• [ ] Analyze Downloader.cs and HLSLiveDownloader.cs to identify shared HTTP client initialization and header handling code
• [ ] Create HttpClientManager.cs to encapsulate HttpClient creation, header configuration, and request execution
• [ ] Refactor both Downloader.cs and HLSLiveDownloader.cs to use the new HttpClientManager
• [ ] Update MyOptions.cs if needed to ensure custom header options flow through the manager
• [ ] Add integration tests in a new test file to verify header injection still works correctly

Add GitHub Action workflow to build and publish release binaries automatically (Windows, Linux, macOS)

The repo has build_latest.yml but checking the file structure, there's no evidence of automated multi-platform release binary generation. The project is a .NET CLI tool (N_m3u8DL-CLI.csproj) that would benefit from automated cross-platform builds. Currently, users likely must compile manually or wait for manual releases. A release workflow would improve distribution and user accessibility.

• [ ] Create a new GitHub Action workflow file .github/workflows/release.yml triggered on version tags (v*.. )
• [ ] Configure the workflow to build self-contained binaries for win-x64, linux-x64, and osx-x64 using dotnet publish
• [ ] Add a step to create a GitHub Release with the compiled binaries attached
• [ ] Update README.md and README_ENG.md to document how users can download pre-built binaries instead of building from source
• [ ] Test the workflow by creating a test tag and verifying binaries are generated and uploaded

• Add unit tests for Parser.cs and MPDParser.cs: the codebase has no visible test directory, and parsing logic is critical for correctness. Start by writing NUnit or xUnit tests for m3u8 and DASH manifest edge cases (empty playlists, relative URLs, encryption key malformation).
• Document the platform-specific decoder registration: the Decode*.cs files (DecodeDdyun.cs, DecodeCdeledu.cs, etc.) are hardcoded into Decrypter.cs with unclear selection logic. Add a configuration file or decorator pattern to make decoder registration explicit and extensible, then document which platform each decoder supports.
• Add integration tests for end-to-end download workflows: create a tests/ folder with mock m3u8 files and segments, then test the full pipeline (Parser → Downloader → Decrypter → FFmpeg) to catch regressions in the maintenance phase.

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.