Valid .m4b rejected before ffprobe runs; scan reports Completed with no file record created

[kevinroberts]

Summary

A valid .m4b file is rejected by an internal pre-check in FfmpegService.RunFfprobeAsync with ffprobe target is not a supported audio file, before ffprobe is ever invoked. ffprobe itself reads the same file without error (exit 0, probe_score=100).

The scan then silently falls back to filename metadata, reports status Completed, and creates no AudiobookFile row. The book shows up in the UI as having missing files, with no error surfaced anywhere except the log.

Environment

Listenarr	1.3.0 (ghcr.io/listenarrs/listenarr:canary)
Runtime	.NET 10.0.11
OS	Linux 6.18.38 (x64), Unraid 7.x
Deployment	Docker, container runs as uid 0
ffprobe	bundled, /app/config/ffmpeg/ffprobe (ffmpeg 7.0.2 amd64 static)
Library storage	XFS (direct disk path, not the Unraid FUSE user share)

The file

Harry Potter and the Half-Blood Prince.m4b — 713,423,915 bytes

format_name=mov,mp4,m4a,3gp,3g2,mj2
duration=66812.839184
probe_score=100
ftyp brand=mp42  (compatible: mp42, isom)

stream 0: aac       audio   mp4a  44100Hz  2ch
stream 1: png       video           (cover art)
stream 2: bin_data  data            (chapters)

Log output

[INF] FfmpegService] Found bundled ffprobe at /app/config/ffmpeg/ffprobe
[WRN] MetadataService] Unable to extract metadata using ffprobe; using public filename metadata
Listenarr.Domain.SystemDiagnostics.Exceptions.FfmpegException: Error running ffprobe for 399
 ---> Listenarr.Domain.SystemDiagnostics.Exceptions.FfmpegException: ffprobe target is not a supported audio file: 399
   at Listenarr.Infrastructure.Ffmpeg.Installation.FfmpegService.RunFfprobeAsync(MetadataFileSource fileSource) in listenarr.infrastructure/Ffmpeg/Installation/FfmpegService.Probing.cs:line 46
   --- End of inner exception stack trace ---
   at Listenarr.Infrastructure.Ffmpeg.Installation.FfmpegService.RunFfprobeAsync(MetadataFileSource fileSource) in listenarr.infrastructure/Ffmpeg/Installation/FfmpegService.Probing.cs:line 96
   at Listenarr.Application.Metadata.Extraction.MetadataService.ExtractFileMetadataAsync(MetadataFileSource fileSource) in listenarr.application/Metadata/Extraction/MetadataService.cs:line 191
[INF] MetadataService] Extracted basic metadata from file: 399
[INF] ScanQueueService] Updated scan job "fec900b9-..." status to Completed

The inner exception comes from Probing.cs:46, i.e. a guard that runs before the ffprobe process is started.

ffprobe disagrees

Running the bundled binary directly, inside the same container, on the same path:

$ /app/config/ffmpeg/ffprobe -v error \
    -show_entries format=format_name,duration,probe_score -of default=nw=1 \
    "/data/media/audiobooks/.../Harry Potter and the Half-Blood Prince.m4b"
format_name=mov,mp4,m4a,3gp,3g2,mj2
duration=66812.839184
probe_score=100
exit=0

What I ruled out

Measured against every file Listenarr has successfully indexed in this library (~52 MP4-family files, ~160 others):

• Not file size — It.m4b (1.2 GB) and Dune.m4b (1.2 GB) index fine; the failing file is 713 MB.
• Not the ftyp brand — 7 successfully indexed files also use brand mp42 (43 use M4A , 2 use isom).
• Not PNG cover art — at least one successfully indexed file also carries a PNG cover stream (46 use mjpeg).
• Not the extension — other .m4b files index fine; .m4b is in AllowedFileExtensions.
• Not the path or filename — the failure follows the file, and renaming/relocating it does not change the outcome.

Notably, Harry Potter and the Order of the Phoenix, Book 5.m4b (757 MB, same series, same folder tree) indexes successfully. The only structural differences from the failing Book 6 file are the ftyp brand (M4A vs mp42) and the cover-art codec plus stream order (aac, bin_data, mjpeg vs aac, png, bin_data) — but both of those factors appear independently among files that index fine, so neither alone explains it.

Secondary problems this exposes

1. The failure is silent. The scan job reports Completed, the API returns success, and the only signal is a [WRN] line in the log. From the UI the book simply appears to have missing files forever. A scan that extracted no usable metadata and wrote no file record arguably should not report success.

2. The error message identifies the file by a bare integer (399 here; it varies between runs — I have observed 382, 386, 395, 399, 400, 401, 408). This looks like a file descriptor rather than a path. It makes the log almost unusable for working out which file failed in a multi-file scan — I had to bisect by re-pointing a single book to find it.

3. Possibly related, possibly separate: every row in AudiobookFiles has Size = 64 in this install, across all 76+ records, regardless of the real file size. Happy to open that separately if it's unrelated.

Related

• [Bug] Download-imported audiobooks missing codec/bitrate/duration (probe empty at import time) #737 (closed) — same subsystem, but the opposite symptom: probe returns empty and a row is written with nulls. Here the probe is refused and no row is written at all.