Listenarrs/Listenarr v1.1.1-canary

Canary 1.1.1

on GitHub

Summary

Fixes the M4B re-grab loop: a monitored audiobook whose file is already at/above cutoff is searched and re-downloaded on every cycle. Replaces #581 with the profile-driven matching approach we agreed on.

Root cause. The cutoff check classified an on-disk file into an ad-hoc label — the container "M4B", or a bare "256kbps" — and looked that string up in the profile's quality rungs. Real rungs are named by codec + bitrate ("AAC 256kbps"), so the label never matched, cutoffMet stayed false, and the audiobook was re-grabbed forever. The same string-label logic existed in three places with three different vocabularies: AudiobookStatusEvaluator (status display), AutomaticSearchService (the actual re-grab driver), and a near-duplicate in LibraryController.

Changes

Added

• QualityMatcher (listenarr.domain/Common): a pure, dependency-free matcher. Given a file's codec/bitrate/lossless facts and a profile, it walks profile.Qualities using the structured Codec / Bitrate / IsLossless fields — falling back to parsing the rung label for seed/legacy profiles that only set Quality + Priority — and: round-down (picks the highest rung the file meets or exceeds); returns a defined CodecMismatch when the file's codec isn't in the profile (instead of the old int.MaxValue silent fallback); matches OGG Vorbis by codec, maps AAC-in-M4B/M4A (incl. the legacy M4B codec group), and normalizes bits/sec → kbps in one place.
• 26 new unit tests (QualityMatcherTests), incl. the exact M4B-loop regression; QualityProfileBuilder extended.

Changed

• The status evaluator, automatic search, and library controller now share a single QualityCutoffEvaluator that calls the matcher.
• Inverted priority comparison corrected. AutomaticSearchService's cutoff check (Priority >= cutoff) and IsQualityBetter (cand.Priority > exist.Priority)...

Automated Canary build

• Version: 1.1.1
• Commit: eb0d610
• Original PR: #648