Download the ffprobe archive on macOS

[krejko]

Summary

FfprobePlatformDefaults.GetDownloadUrl() returns the ffmpeg archive for macOS, but every consumer looks for a binary named ffprobe in the extracted files. The download succeeds and the install then fails:

[INF] Downloaded ffprobe archive SHA256=9a810d222862a7230fd7035c91e32beb605af7501c3517580f2bc1eb8faddacc
[INF] No ffprobe binary found in extracted files under .../.env/development/config/ffmpeg
[WRN] ffprobe install did not produce the expected binary at .../config/ffmpeg/ffprobe
[WRN] ffprobe was not installed or auto-install disabled

The residue in the config directory confirms the wrong asset is fetched — a 78 MB file named ffmpeg, and no ffprobe:

-rw-r--r--  78829164  ffmpeg      <- extracted from the downloaded archive
                                  <- no ffprobe

Consequence: on macOS the unmatched scan runs with ffprobePath == null, so embedded-tag extraction is skipped entirely and books import with only path-derived metadata.

macOS is the only affected platform. Linux downloads a static tarball containing both binaries, and the Windows "essentials" archive ships ffprobe.exe — so both happen to satisfy the ffprobe search by accident.

Changes

Fixed

• Point the macOS download at the ffprobe release (https://evermeet.cx/ffmpeg/getrelease/ffprobe/zip) rather than the ffmpeg archive.

The getrelease endpoint tracks the current build instead of pinning ffmpeg-6.0.zip, which is several years old.

Testing

Downloaded the corrected URL and confirmed the archive contains a working ffprobe that depends only on system frameworks:

$ curl -sSL -o ffprobe.zip "https://evermeet.cx/ffmpeg/getrelease/ffprobe/zip"   # 26 MB
$ unzip -q ffprobe.zip && ./ffprobe -version
ffprobe version 9.0.1-tessus  https://evermeet.cx/ffmpeg/

Placed at the expected path, the running instance picks it up with no restart, and tag extraction works against a real library:

GET /api/v1/ffmpeg/info
{"ffprobePath":".../.env/development/config/ffmpeg/ffprobe"}

[INF] Found bundled ffprobe at .../config/ffmpeg/ffprobe

TAG:title=The Ickabog
TAG:comment=The Ickabog is coming… A mythical monster, a kingdom in peril…
TAG:description=The Ickabog is coming… A mythical monster, a kingdom in peril…

Notes

Only the URL changes; the download, checksum, extraction and install paths are untouched. Users who already have a working ffprobe in their config directory are unaffected, since installation short-circuits when the binary is present.

🤖 Generated with Claude Code

[m4bard]

We have both written this fix, which I only noticed sweeping our own branches. Ours is #786, opened before yours and stale on 1.2.2, so I am not raising this to stake a claim. There is one substantive difference and I think it matters.

The URLs differ in where the extension sits. Yours is https://evermeet.cx/ffmpeg/getrelease/ffprobe/zip, ours is https://evermeet.cx/ffmpeg/ffprobe-6.0.zip.

FfprobeArchiveExtractor.ExtractAsync dispatches on the URL's suffix, at d25b3e11:

if (downloadUrl.EndsWith(".zip", ...) || downloadUrl.EndsWith(".ffmpeg.zip", ...))
{
    // ZipArchive extraction
}

if (downloadUrl.EndsWith(".tar.xz", ...) || downloadUrl.EndsWith(".tar.gz", ...) || downloadUrl.EndsWith(".tgz", ...))
{
    // tar extraction
}

File.Move(tmpFile, safeFfprobePath);
return true;

getrelease/ffprobe/zip ends in /zip rather than .zip, so EndsWith(".zip") is false. It matches neither branch and reaches the fallthrough, which moves the downloaded file to the ffprobe path and returns true. That would leave a ZIP archive installed under the name ffprobe, with the installer reporting success. The next thing to run it gets an exec format error rather than anything pointing back here.

I have read that rather than run it. I have not downloaded from either URL, and I do not know whether evermeet's getrelease path serves a redirect that would change what the extractor sees, though the suffix test happens on the configured string rather than on any final URL, so I would not expect a redirect to help.

If the getrelease form is the one you want, and it does look like the more durable choice since it is not pinned to a version, then the extractor needs to learn about it. Adding /zip to that first condition would do it, or dispatching on sniffed content rather than the string.

I have no attachment to our URL and would rather one of these landed than that we both sat here. Worth saying that our branch carries a test asserting every platform's configured URL ends in a suffix the extractor recognises, which is the check that would have caught this, and it would apply to your URL just as well as ours. Happy to send that test on its own against whichever URL you settle on, if that is useful.