AudiobookStatusEvaluator.DeriveQualityLabel produces labels that never match QualityProfile.Qualities keys → all books report quality-mismatch

[timk75]

Summary

Audiobooks always show quality-mismatch even when the file matches the profile's cutoff quality, because AudiobookStatusEvaluator.DeriveQualityLabel returns labels (e.g. "320kbps", "lossless") that never appear as keys in QualityProfile.Qualities (e.g. "MP3 320kbps", "FLAC").

Repro (canary 0.2.73, commit 6fe911a0)

1. Create a QP via POST /api/v1/qualityprofile with a quality { "quality": "MP3 320kbps", ... } and cutoffQuality: "MP3 320kbps".
2. Import an audiobook whose only file is a 320 kbps MP3.
3. Trigger a library scan. Expected: status: "quality-match". Actual: status: "quality-mismatch".

Same symptom for FLAC files against a QP with quality "FLAC": derived label is "lossless", profile key is "flac" → no hit.

Root cause

listenarr.api/Services/AudiobookStatusEvaluator.cs lines 105–138 build qualityPriority keyed on Normalize(quality.Quality) — i.e. the lowercased profile-quality string such as "mp3 320kbps" or "flac".

DeriveQualityLabel (lines 141–192) produces:

• "320kbps", "256kbps", "192kbps", "<rounded>kbps" for lossy files (no codec prefix), and
• "lossless" for FLAC/ALAC/etc (no codec name).

qualityPriority.TryGetValue therefore always misses, returns int.MaxValue, the cutoff comparison fails, and every file falls through to return QualityMismatch; on line 138.

Impact

• Every audiobook in the library reports quality-mismatch unless the legacy audiobookQuality column is already populated (rare for fresh imports).
• The "Below Cutoff" UI label is meaningless — it fires for files that perfectly meet the cutoff.
• Affects all default profiles seeded via the UI as well as profiles created via API.

Proposed fix

DeriveQualityLabel should produce labels that round-trip with QualityProfile.Qualities[i].Quality:

• For lossless containers/codecs, return the codec name itself: "flac", "alac", "wav", etc., not "lossless".
• For lossy files, return "<codec> <bucket>kbps" with the codec inferred from Codec/Container/Format ("mp3 320kbps", "aac 192kbps", "opus 128kbps").

Patch (running locally as a test):

private static string DeriveQualityLabel(AudiobookFileStatusInfo? file, string? audiobookQuality)
{
    var normalizedAudiobookQuality = Normalize(audiobookQuality);
    if (normalizedAudiobookQuality.Length > 0) return normalizedAudiobookQuality;

    var container = Normalize(file?.Container);
    var codec = Normalize(file?.Codec);
    var format = Normalize(file?.Format);

    if (container.Contains("flac", StringComparison.Ordinal) || codec.Contains("flac", StringComparison.Ordinal)) return "flac";
    if (container.Contains("alac", StringComparison.Ordinal) || codec.Contains("alac", StringComparison.Ordinal)) return "alac";
    if (container.Contains("wav",  StringComparison.Ordinal) || codec.Contains("wav",  StringComparison.Ordinal)) return "wav";
    // ... (aiff/ape/dsd/wavpack analogous)

    string codecName = "";
    if      (codec.Contains("mp3")    || container.Contains("mp3")  || format.Contains("mp3"))                              codecName = "mp3";
    else if (codec.Contains("aac")    || container.Contains("m4a")  || container.Contains("m4b") || container.Contains("mp4")) codecName = "aac";
    else if (codec.Contains("opus")   || container.Contains("opus")) codecName = "opus";
    else if (codec.Contains("vorbis") || container.Contains("ogg"))  codecName = "ogg vorbis";

    if (file?.Bitrate is int bitrate)
    {
        var kbps = bitrate >= 1000 ? bitrate / 1000d : bitrate;
        int bucket = kbps >= 320 ? 320 : kbps >= 256 ? 256 : kbps >= 192 ? 192 : kbps >= 128 ? 128 : kbps >= 96 ? 96 : kbps >= 64 ? 64 : (int)Math.Round(kbps);
        return codecName.Length > 0 ? $"{codecName} {bucket}kbps" : $"{bucket}kbps";
    }
    return codecName.Length > 0 ? codecName : format;
}

Bucket cutoffs match the existing schema seeded by qualityprofile/default-quality-formats.

Happy to send a PR if the above approach is acceptable. Currently testing this patched evaluator against a 48-book library on canary 0.2.73.

[timk75]

Hit this on a current canary install (Listenarr 0.3.1) and tracked it down — the symptom in my library was a stack of …(1) / (2) / (3) / (4) staging folders under Downloads/complete/audiobooks/ for any monitored M4B book with a matching indexer release, plus duplicate metadata files in the library dir. SABnzbd was downloading the same .nzb every ~6 hours forever; the qBit-MAM client did the same on the torrent side.

The Listenarr log line that gives it away:

Cutoff not met for "Artificial Condition" (id=179):
  cutoff met=False, best existing quality=M4B

Despite the on-disk file being m4b / aac / 64 kbps, which should satisfy the AAC 64kbps rung seeded by QualityProfileService.EnsureProfileHasRequiredQualitiesAsync.

Root cause is AudiobookStatusEvaluator.DeriveQualityLabel: it emits labels like "M4B", "lossless", or "320kbps"/"64kbps" (no codec prefix), but QualityProfile.Qualities keys are codec-prefixed ("AAC 320kbps" ... "AAC 64kbps", "MP3 320kbps" ... "MP3 64kbps"). The dictionary lookup misses, priority defaults to int.MaxValue, the cutoff is never met, and a matching MP3 release at any rung scores as an "upgrade".

Workaround for anyone hitting this before a fix lands: set the audiobook monitored=false (re-grab loop only fires for monitored books). DELETE via the API works (monitored field is silently ignored on PUT). Files on disk are preserved as long as deletedFiles=0.

Sent a fix as #581 — patches the deriver to detect the codec (including m4b/m4a/mp4 → aac), bucket the bitrate to the seeded rungs, and emit "<codec> <bucket>kbps" so the labels round-trip with the QP. Tests cover the M4B regression plus AAC / MP3 / FLAC / ALAC / WavPack paths and the legacy hint fall-through.