macOS: ffprobe never installs — metadata import broken on every Mac

[m4bard]

macOS is borked: FfprobePlatformDefaults points it at an ffmpeg archive (evermeet…/ffmpeg-6.0.zip) with no ffprobe in it, so <config>/ffmpeg/ffprobe never exists and every import fails ("Failed to extract metadata from file"). Confirmed on macos-latest. (Repro: fresh osx-x64 install → import anything.)

But it's really a symptom of how ffprobe gets fetched, which is rough across the board:

• unpinned + unverified — rolling URLs, GetChecksum() returns null
• slow + racy on first boot — every fresh install downloads a whole ffmpeg archive on startup; Docker is slower to become usable, and imports fail until it lands
• version drift — Windows (gyan 8.x) vs Linux (johnvansickle 7.x): same file, different metadata

Two ways I could help — I'd lean toward (b):

a) Fix macOS only — a one-liner (point it at a source that has ffprobe). Quick, but a band-aid: the fetch stays unpinned, unverified, and slow/racy on every other platform.
b) Adapt what I already built for listenarr-testdata — the sustainable path. It:

• pulls a pinned ffprobe for every platform you ship, from one source (jellyfin-ffmpeg)
• verifies it against GitHub's release-asset digest before use (out-of-band; a bad download is refused)
• ships only ffprobe — you never spawn ffmpeg

Happy to PR either.

[m4bard]

I built the first of the two options above: #786.

The narrow cause turned out to be the artifact rather than the source. evermeet ships one binary per archive, and the platform default points at the ffmpeg one, so the download succeeds and there is no ffprobe inside it to install. evermeet publishes ffprobe separately at the same version, so #786 points macOS there and changes nothing else. I checked both archives before touching any code: ffmpeg-6.0.zip holds a single ffmpeg entry, ffprobe-6.0.zip holds a single ffprobe that file reports as Mach-O 64-bit x86_64, which is the right architecture given the project publishes osx-x64 only.

Two things I found while doing it that are worth recording here rather than in the PR.

FfprobeArchiveExtractor chooses zip or tar handling from the URL suffix, so any URL that does not end in .zip, .tar.xz, .tar.gz or .tgz downloads cleanly and then extracts nothing. That rules out evermeet's getrelease/ffprobe/zip endpoint, which redirects to the current release and looks like the better thing to pin to. It ends in /zip, so it would fail the same quiet way this bug does. #786 has a test for it.

The github: provider is not gated on the platform default being null. FfmpegService sets the default and then overrides it whenever provider discovery succeeds, which means a Mac user can unblock themselves today by setting Ffmpeg.Provider, without waiting for a release.

The second option is untouched and still worth doing. GetChecksum() returns null on every platform, so all three downloads are unpinned and unverified, and macOS is simply where that turns fatal instead of merely risky. Switching the defaults to the github: provider with a pinned release and a checksum would cover all three at once, and most of the machinery is already there. The open questions are which source to pin to and whether you want that behaviour change for existing Linux and Windows installs, which is your call rather than mine. Happy to build it if you want it.