The download finished, but Lidarr will not import it. This page covers the match-quality rules Lidarr applies to imports, why an otherwise-valid file can still be rejected, when human intervention is required, and how to use manual import to force an outcome when the matcher cannot.
If you have not imported anything yet and are setting up a fresh library, start with Importing an Existing Library instead — this page is for diagnosing imports that do not auto-complete, 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. Any other extension is ignored entirely — Lidarr will not attempt to import, rename, or track it. If your files are not being picked up 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 could not find a release that resembles the file closely 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. The score is converted to a similarity percentage for user-facing messages.
For a new download, Lidarr requires:
If the album scores 85% overall but one track inside it only matches at 50%, the whole import is rejected — 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 are excluded 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 are not configuration values — they are 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. The weights are adapted from beets' default configuration, with MusicBrainz IDs treated 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 fingerprinting is allowed is controlled by 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 regularly land in a state where fingerprinting runs but does not rescue them, the root cause is usually that the files do not exist in MusicBrainz at all — no fingerprint match is possible for a release that is not in the database.
Some situations cannot be resolved by the automatic matcher, no matter how the settings are tuned. These are the cases where 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 is not in MusicBrainz, the matcher has nothing to match to. Two options:
Some MB releases are catalogued with 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 usually 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 does not 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 was not originally designed to handle. The tag data may be correct for the source but incomplete against a MusicBrainz release group, and the automatic matcher will not resolve it. Manual import is the expected path for these cases until the plugin-specific import flows mature — it is not a workaround, it is the intended workflow.
Import lists (Spotify, Last.fm, Trakt, etc.) feed entries into Lidarr that have to be resolved to a MusicBrainz release group before anything can be added. 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:
There is no user-facing setting to bias the metadata server's ordering — it is an upstream decision.
Manual import is the override path when the automatic matcher cannot 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 does not re-run match-quality, free-space, not-currently-unpacking, upgrade-or-not, or any other specification — the decisions are treated as approved by user choice. The rejections shown inside the manual-import dialog are informational, to help you decide what to import; they are not 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 does not 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 a specific pressing to be matched rather than whichever one happened to score 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 is not 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 the weights are adapted 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.