ffprobe is installed from unpinned, unverified URLs, and the platforms disagree

[m4bard]

The setup

FfprobePlatformDefaults.GetDownloadUrl picks one of three third-party URLs:

• Linux: johnvansickle.com/ffmpeg/releases/ffmpeg-release-{amd64,arm64}-static.tar.xz
• Windows: gyan.dev/ffmpeg/builds/ffmpeg-release-essentials.zip
• macOS: evermeet.cx/ffmpeg/ffprobe-6.0.zip

Two of those are rolling pointers, so the URL stays the same while the file behind it changes. GetChecksum() returns null, which leaves expected empty on the default path, so the mismatch branch in FfmpegService never fires. Whatever the URL serves that day gets extracted and run.

What that produces right now

I run a cross-platform harness that fetches ffprobe on every RID Listenarr ships and compares the fields FfprobeMetadataMapper reads against a committed golden. Latest run, today:

platform	current source	result
linux-x64	johnvansickle	matches golden
linux-arm64	johnvansickle	matches golden
osx-x64 (under Rosetta)	evermeet	no ffprobe in the archive (#777)
win-x64	gyan	disagrees with golden

The Windows URL now serves ffprobe 8.1.2. On the same input files it reports:

sample.mp3  format.duration   1.071020  ->  1.000000
sample.mp3  format.bit_rate   34277     ->  36712

Both of those are mapped: format.duration becomes metadata.Duration and format.bit_rate becomes metadata.BitRate. The m4a and m4b samples also drop vendor_id from stream.tags, which I do not think reaches a field, but it shows the tag dictionary is not stable across builds either.

So a book imported on Windows and the same book imported on Linux get different durations and bit rates recorded. I measured that today. I cannot tell you when it started, because the URL keeps no history and my previous run's logs have expired.

Most of the fix already exists

FfmpegConfig.Provider accepts github:<owner>/<repo>. When it is set, FfprobeGithubAssetDiscoverer finds a checksum asset in the release, FfprobeChecksumParser pulls the line for the downloaded file, and FfmpegService compares it and aborts the install on mismatch. That is the behaviour you want and it is already wired up. The default path just never reaches it.

One gap if you point that at a multi-platform release repo: asset selection filters on the Arch hint as a plain substring and then takes the first archive it sees, with no notion of operating system. It happens to work with jellyfin-ffmpeg because their asset names fold platform and arch into one token (portable_linux64-gpl, portable_macarm64-gpl), so the hint can carry both. A source that names them separately would need an OS-aware selector.

Prior art in the family

Lidarr has the same shape of problem with fpcalc and solved it by not downloading at runtime at all. The binaries are committed per RID under src/Runtimes/<rid>/fpcalc, eleven of them, and src/Runtimes/README records where they came from: a pinned release tag, chromaprint v1.5.1. FpcalcCheck then reports a health warning and disables fingerprinting when the binary is missing or too old, rather than failing quietly.

Two things there are worth stealing. The source is a pinned GitHub release rather than a vendor's "latest" URL, and a health check makes the degraded state visible.

Options

A. Pin and checksum what you have. Smallest change: replace the rolling URLs with versioned ones and return real hashes from GetChecksum(). Fixes reproducibility and drops the unverified download. Does not fix macOS, since evermeet ships no ffprobe in the ffmpeg archive (that is #786, separately).

B. Flip the default to a durable GitHub-release source. Reuses the github: path that already verifies and aborts. Needs the OS-aware asset selection above. jellyfin-ffmpeg reproduces the golden on all five cells I test, including macOS, so on the evidence I have it is a behaviour-safe swap.

C. Ship it per RID, like Lidarr. No network at first boot and nothing to verify at runtime, at the cost of repo or release size.

A is the cheap one. I would pick B. C is the most robust of the three and much the largest change.

There is a smaller point buried in B. evermeet publishes x86_64 only, so Macs run ffprobe under Rosetta today, while jellyfin ships a native portable_macarm64-gpl build alongside portable_mac64-gpl. Listenarr has no osx-arm64 RID, so that is not actionable on its own, but it is a reason to prefer a source that has the build waiting.

Offer

The harness is at https://github.com/m4bard/listenarr-testdata and the matrix is reproducible. If you tell me which option you want I will open the PR. If none of them, that is a useful answer too and I will leave the area alone.

[m4bard]

Went looking at how the video *arr projects get ffprobe, and it is a fourth option I did not put in the issue. Both of them take it as a NuGet package rather than downloading it at first boot.

Sonarr:

<PackageReference Include="Openur.FFMpegCore" Version="5.4.0.37" />
<PackageReference Include="Openur.FFprobeStatic" Version="8.1.2.397" />

Radarr does the same thing with its own names, Servarr.FFMpegCore 4.7.0-26 and Servarr.FFprobe 5.1.10.124, off the Servarr Azure feed rather than nuget.org. That feed answers anonymously, so it is consumable from outside the org. Lidarr, Readarr and Prowlarr have no ffprobe dependency at all.

The package is native assets per RID:

runtimes/linux-x64/native/ffprobe
runtimes/linux-arm64/native/ffprobe
runtimes/osx-x64/native/ffprobe
runtimes/osx-arm64/native/ffprobe
runtimes/win-x64/native/ffprobe.exe
  ... plus linux-arm, win-x86, freebsd-x64, freebsd-arm64

That is every RID this project ships, and then some. Restore puts the right one in the build output, so there is no download at first boot, nothing to checksum at runtime, and the version is pinned by the package reference the same way every other dependency is. Options A and B each solved half of that.

It also covers macOS properly rather than working around it. osx-arm64 is in the package, so the Rosetta point I raised on #786 stops being a tradeoff. Worth saying plainly: if you go this way, #786 is unnecessary and I would close it. The narrow URL fix only matters while the download path exists.

The part you would want to check before taking Sonarr's version

Provenance on the specific package is thinner than the pattern. The Openur organisation was created in July 2025, has five repositories, and ffprobe-static-build, which the nuspec names as the source, has no license file and no stars. The nuspec author is "Openur Team". Sonarr depending on it is real signal, and it is a static ffmpeg build rather than anything exotic. It is also a package with no long public track record that ships an executable into every install.

Radarr's Servarr.FFprobe has better provenance, being the project's own infrastructure, but it sits on an Azure DevOps feed rather than nuget.org and is on ffmpeg 5.1.10 against Sonarr's 8.1.2.

So the pattern is well established in the family and the choice of package is a judgement I would rather you made. Building your own equivalent is also a real option, since the packages are just static builds laid out per RID, and that is the version with no third-party trust in it at all.

Happy to prototype whichever of these you prefer, or to leave it if the download path is staying for now.