The download finished, but Lidarr won't import it. This page covers the match-quality rules Lidarr applies to imports, why Lidarr can still reject an otherwise-valid file, when you need to intervene manually, and how to use manual import to force an outcome when the matcher can't.
If you haven't imported anything yet and are setting up a fresh library, start with Importing an Existing Library instead — this page is for diagnosing imports that don't autocomplete, not for the first-time setup.
Lidarr only processes files with these extensions: .mp2, .mp3, .m4a, .m4b, .m4p, .ogg, .oga, .opus, .wma, .wav, .wv, .flac, .ape, .aif, .aiff. Lidarr ignores any other extension entirely — it won't attempt to import, rename, or track it. If Lidarr isn't picking up your files at all, confirm they have a supported extension before troubleshooting further.
Every file Lidarr considers importing runs through a decision pipeline. For an import to succeed, the file must pass every specification. A single rejection reason anywhere in the pipeline stops the import. The pipeline is strict by design: incorrect imports are hard to undo, so Lidarr errs on the side of refusing rather than guessing.
The most common rejection category is match quality — Lidarr couldn't find a release that resembles the file well enough.
Lidarr computes a normalised distance score between what it sees on disk (file tags, filenames, duration, track count) and each candidate release in its metadata. Lower distance = closer match. Lidarr converts the score to a similarity percentage for user-facing messages.
For a new download, Lidarr requires:
If the album scores 85% but one track inside it only matches at 50%, Lidarr rejects the whole import — that one poor track is enough to fail the album.
For importing existing library files (when you point Lidarr at a root folder you already had on disk), the rules are more lenient:
missing_tracks and unmatched_tracks from the score. This is why an existing library can import successfully even if some files are missing or there are extras.Standalone track imports outside the album context use a 60% similarity threshold (distance ≤ 0.40).
These aren't configuration values — they're constants in the Lidarr source code. See Where this lives in the source below.
The distance score is a weighted combination of how well each field matches. Lidarr adapts the weights from beets' default configuration, with MusicBrainz IDs as the strongest signals:
| Signal | Weight | Notes |
|---|---|---|
recording_id |
10.0 | MusicBrainz Recording MBID. If present and correct, imports almost always succeed. |
album_id |
5.0 | MusicBrainz Release MBID. |
artist |
3.0 | Artist name (Levenshtein distance after normalisation). |
album |
3.0 | Album/release title (same). |
track_title |
3.0 | Per-track title. |
track_artist |
2.0 | Per-track artist (matters for compilations). |
track_length |
2.0 | Duration in seconds. |
tracks |
2.0 | Track-count agreement. |
source |
2.0 | Source medium (digital / CD / vinyl / etc). |
media_count, media_format, year, track_index |
1.0 each | |
unmatched_tracks |
0.9 | Penalty for files that don't map to any MB track. |
missing_tracks |
0.6 | Penalty for MB tracks with no corresponding file. |
country, label, catalog_number, album_disambiguation |
0.5 each | Tiebreakers, not primary signals. |
The practical takeaway: MusicBrainz Recording IDs and Release IDs are the dominant signals. Files tagged with correct MBIDs (by MusicBrainz Picard, for example) almost always import. Files without MBIDs rely on artist/album/title matching and are far more sensitive to tag quality.
If the best candidate release is still worse than threshold, Lidarr can attempt to identify the files by acoustic fingerprint instead of tags. This is the fallback path that sometimes rescues imports where the tags are wrong or missing.
Fingerprinting kicks in when any of the following is true:
Whether Lidarr allows fingerprinting depends on the Allow Fingerprinting setting under Settings → Media Management:
Never — fingerprinting is disabled.New Files — fingerprint new downloads only (default on most installs).Always — fingerprint even on library imports.Fingerprinting is slower than tag-based matching and hits an external service. If downloads consistently land in a state where fingerprinting runs but doesn't rescue them, the root cause is that the files don't exist in MusicBrainz at all — no fingerprint match is possible for a release that isn't in the database.
The automatic matcher can't handle some situations, no matter how you tune the settings. For these cases, manual import is the expected path, not a workaround.
Lidarr only imports against releases that exist at MusicBrainz (via the metadata server). If the specific pressing or edition you have isn't in MusicBrainz, the matcher has nothing to match to. Two options:
Some MB releases have incomplete track lists. If your files have 12 tracks and the MB release only lists 10, unmatched_tracks applies a significant penalty (weight 0.9) and the import can fail even with otherwise-good metadata. The fix is either to complete the MB release or to manually import.
Without tags, Lidarr matches on the filename and duration only. This works for well-named files (01 - Artist - Album - Track.flac) but breaks on generic filenames (track01.mp3). Run a tagger — MusicBrainz Picard is the reference tool — before asking Lidarr to import.
The nightly branch supports third-party plugins for indexers and download clients — streaming services, peer-to-peer networks, and other sources. See Plugins for the install path and current compatibility notes.
Content pulled through plugins sometimes doesn't fit Lidarr's core import model cleanly: single tracks, partial releases, streaming-service rips, and per-track purchases are all common plugin outputs that the core matcher wasn't originally designed to handle. The tag data may be correct for the source but incomplete against a MusicBrainz release group, and the automatic matcher won't resolve it. Manual import is the expected path for these cases until the plugin-specific import flows mature — it isn't a workaround, it's the intended workflow.
Import lists (Spotify, Last.fm, Trakt, etc.) feed entries into Lidarr that Lidarr must resolve to a MusicBrainz release group before it can add anything. The resolution depends on whether the list provides an MBID:
This matters because MusicBrainz distinguishes singles from albums at the release-group level — a track called Blinding Lights exists on both the "Blinding Lights" single release group and the After Hours album release group. If the metadata server's search happens to rank the single higher than the album (track-count match, exact title match, locale, or any other factor the server uses), the list entry resolves to the single, not the album.
Practical consequences:
No user-facing setting biases the metadata server's ordering — it's an upstream decision.
Manual import is the override path when the automatic matcher can't resolve a file. Two entry points:
The manual-import dialog lets you pick:
Manual import bypasses the specification pipeline entirely. When you click Import, Lidarr doesn't re-run match-quality, free-space, not-currently-unpacking, upgrade-or-not, or any other specification — Lidarr treats the decisions as approved by your choices. The rejections shown inside the manual-import dialog are informational, to help you decide what to import; they aren't blockers once you commit.
The only checks still enforced at manual-import time are filesystem- and DB-level:
If manual import fails, the reason will be one of the above — a filesystem or DB failure, not a match-quality rejection.
Lidarr's automatic import matcher picks the MusicBrainz release (pressing) that scores closest to the files on disk. It doesn't prefer one pressing over another based on format (CD / Digital Media / Vinyl) — media_format has a low weight in the distance model and only penalises releases whose format is Unknown in MusicBrainz. If you want Lidarr to match a specific pressing rather than whichever one scored closest, you have three options.
Option 1 — Tag with the correct MusicBrainz Release MBID. The album_id distance signal (weight 5.0) is the second-strongest signal in the model after Recording IDs. If your files carry the MusicBrainz Album Id tag set to the Release MBID for the pressing you want, the automatic matcher will nearly always select it. Use MusicBrainz Picard, beets, or Harmony to write the tag before the import runs. Make sure you use the Release MBID, not the Release Group MBID — those are different IDs.
Option 2 — Use manual import and pick the pressing. The manual-import dialog lets you select the specific release within a release group. Once you choose a pressing and click Import, that pressing becomes the attached release for those files. No tags need changing. See Using manual import above for the two entry points.
Option 3 — Switch the active release on the album page. Each album in Lidarr has a currently-active release. You can change it by going to the album page, clicking Edit, and selecting a different release from the dropdown. After saving, a new import triggered from Activity → Queue or a manual import will match against that release.
None of these options work retroactively on files Lidarr has already imported and is tracking. For already-imported files, use manual import to re-import with a different pressing selection, which overwrites the attached release in the database.
For background on why format preference isn't automatic and the open feature request on this, see FAQ → Can Lidarr prefer a specific pressing or format during import?.
For advanced readers who want to verify the rules or trace a specific rejection, the relevant code lives under src/NzbDrone.Core/MediaFiles/TrackImport/ in the Lidarr source tree:
Specifications/CloseAlbumMatchSpecification.cs — album-level and worst-track thresholds (0.20 and 0.40).Specifications/CloseTrackMatchSpecification.cs — standalone track threshold (0.40).Identification/Distance.cs — weighted field contributions; comment at the top notes that Lidarr adapts the weights from beets' defaults.Identification/IdentificationService.cs — Identify() implements the four-step flow (group → candidates → best match → fingerprint if worse than threshold); ShouldFingerprint() documents when fingerprinting triggers.AlreadyImportedSpecification.cs, AlbumUpgradeSpecification.cs, FreeSpaceSpecification.cs, MoreTracksSpecification.cs, NoMissingOrUnmatchedTracksSpecification.cs, NotUnpackingSpecification.cs, ReleaseWantedSpecification.cs, SameTracksImportSpecification.cs, UpgradeSpecification.cs.Manual/ManualImportService.cs — Execute() builds LocalTrack objects from user choices and creates approved ImportDecisions directly, bypassing the specification pipeline. The only pre-import rejection is the root-folder check.ImportApprovedTracks.cs — the post-approval path. Handles the remaining checks (dedup, filesystem, artist/album add) for both automatic and manual imports.src/NzbDrone.Core/ImportLists/ImportListSyncService.cs — MapAlbumReport() takes .FirstOrDefault() from the metadata-server search for title-only list entries. Direct MBID lookups go through SkyHookProxy.SearchForNewAlbum with a lidarr:<mbid> query.src/NzbDrone.Core.Test/MediaFiles/TrackImport/ — IdentificationServiceFixture.cs, AlbumDistanceFixture.cs, TrackDistanceFixture.cs, and ImportDecisionMakerFixture.cs are the most useful starting points for understanding how specific cases score.