fix(windows): keep output folders out of yt-dlp templates

[anhtahaylove]

Summary

• keep yt-dlp output templates filename-only and pass the download directory through --paths home:
• apply the same output-directory handling to metadata sidecar downloads
• preserve filename metadata prefixes, queue/playlist numbering, chapter numbering, and --output-na-placeholder unknown
• recover output paths only from the current yt-dlp invocation: a unique --print-to-file after_move:filepath capture plus paths emitted by that same child process
• canonicalize recovered paths and reject missing, unsupported, or outside-output-directory files
• preserve multiple output paths for split chapters and plugin workflows

Tests

• bun run biome check --write .
• bun run tsc -b
• bun test — 101 passed
• cargo test playlist_chapter_tests --lib — 18 passed
• cargo check
• cargo fmt --all -- --check
• git diff --check

[vanloctech]

Thanks for the PR. The --paths home: change makes sense and should help keep yt-dlp output templates filename-only on Windows.
One concern before merging: the new fallback that picks the newest media file in the output directory is not scoped to the current download job. If multiple downloads run in the same folder, or another process/plugin creates a media file around the same time, Youwee could attach the wrong filepath to Library history and download.completed workflows.
Could you make that fallback deterministic? For example, snapshot the output directory before starting yt-dlp, then after success only consider files that are new or modified after this job started. For split chapters, it should also preserve multiple output files rather than reducing everything to a single newest file.
The rest of the approach looks good to me; I mainly want to avoid recording or post-processing the wrong file in concurrent/download-heavy workflows.

[anhtahaylove]

Updated and force-pushed after rebasing onto the current upstream/main.

What changed:

• snapshots the output directory immediately before each yt-dlp process;
• fallback only accepts media files created or modified after that snapshot;
• keeps every recovered filepath for split chapter outputs while still selecting the newest changed file as the primary history filepath;
• ignores unchanged pre-existing media and non-media files.

Windows validation:

• bun run biome check --write .
• bun run tsc -b
• cargo test output_fallback_only_returns_files_changed_by_this_job --lib
• cargo test output_filepaths_merge_printed_and_recovered_chapters --lib
• cargo check
• rustfmt --edition 2021 --check src/commands/download.rs
• git diff --check

All checks passed. The updated head is 0049b76.

[vanloctech]

Thanks for the update. The --paths home: direction makes sense and should help keep yt-dlp templates filename-only on Windows.

I still can’t merge this yet for two reasons:

1. The PR is currently conflicting with main. This area has changed since the PR was opened, especially around filename metadata in build_output_template(). Please rebase and make sure the new --paths home: approach preserves filename metadata prefixes, queue/playlist numbering, chapter numbering, and --output-na-placeholder.

2. The fallback based on “newest changed media file” is better than before, but it is still not fully scoped to the current download job. It excludes unchanged pre-existing files, but another download/process writing to the same folder after the snapshot could still be picked up and recorded as the Library filepath or plugin output. Please make the recovery path more deterministic, or add stronger safeguards/tests around concurrent/unrelated file changes.

The core idea is good, but I’d like those points handled before merge.

[anhtahaylove]

Thanks — I rebased onto current main (e104390) and force-pushed 57d9f97, addressing both points.

• --paths home: remains separate from the filename-only -o template.
• Regression coverage verifies filename metadata prefixes, queue/playlist numbering, chapter numbering, and --output-na-placeholder unknown.
• The directory “newest changed media file” scan has been removed entirely.
• Recovery now only accepts paths tied to this invocation: its unique --print-to-file after_move:filepath file plus paths emitted by the same yt-dlp child process.
• Recovered paths are canonicalized, must exist, must be supported media files, and must remain inside the configured output directory.
• The concurrency regression test creates an unrelated media file in the same directory and an outside-root file; both are ignored while the current job’s main/chapter outputs are retained.

Validation:

• bun run biome check --write . — passed
• bun run tsc -b — passed
• bun test — 101 passed
• cargo test playlist_chapter_tests --lib — 18 passed
• cargo check — passed
• cargo fmt --all -- --check — passed
• git diff --check — passed

I also ran cargo test --lib on Windows: 222 tests passed; the only 2 failures are existing plugin security tests that assert Unix /tmp paths and are outside this PR’s diff.