This page explains the model Lidarr uses to manage music, why that model depends on MusicBrainz, and when Lidarr is (and isn't) the right tool for your library. If you just want to install and start using Lidarr, read the Quick Start first. Come back here when you want to understand why something behaves the way it does.
Lidarr is a music library management system, data aggregator, and automation platform for finding and downloading media. At a high level it follows the same principles as the other Arr applications (Sonarr, Radarr, etc.), but music introduces complications that film and TV don't.
Unlike movies and TV shows, music has no consistent set of standards for tagging, naming, or storage. Distribution has shifted from physical media to electronic over decades, which has widened the variation rather than narrowed it. Opinions on how to handle music-library management are wide and varied, and Lidarr has to pick one.
The choice Lidarr makes is to lean on third-party metadata to impose order. Every album and artist in Lidarr corresponds to a record in an external data source, and Lidarr uses that record to categorize, tag, and manage files. Everything else in this page follows from that decision.
If the data doesn't exist in third-party services, Lidarr can't manage it.
Lidarr organizes music around the Release standard from MusicBrainz. Every item Lidarr manages must correspond to a Release in its metadata source.
Examples of Releases:
If something you want to manage doesn't exist as a Release in the metadata source, Lidarr can't handle it. Lidarr has no "add it locally only" escape hatch.
Lidarr is audio-only. MusicBrainz marks some recordings as video (music videos, live video streams, etc.). Lidarr skips those entirely and won't search for, grab, or import a release where all tracks carry the video flag.
You can only manage
Releasesin Lidarr if they exist in third-party services.
MusicBrainz distinguishes two levels: the release group ("the album") and the release ("a specific edition of the album"). The 2005 studio album is a release group. The 2005 CD edition, the 2005 vinyl pressing, and the 2015 remastered reissue are all releases within that release group.
Lidarr's Album corresponds to MusicBrainz's release group, not its release. When Lidarr adds an album, it's adding the release group and tracking one of its releases as the "active" release for your library.
Two consequences follow:
Individual tracks aren't addable in isolation. A recording released as part of an album lives inside that release group. To fetch it, add the release group and let Lidarr fetch the whole thing. Where MusicBrainz classifies a track as a single (its own release group of type Single), Lidarr can handle it. That's one of the reasons Metadata Profiles expose Single as a release-group-type toggle separate from Album.
The Metadata Troubleshooting page covers the related failure modes. For example, it describes what happens when a release group has Type: Unknown and your Metadata Profile filters it out.
An Artist in Lidarr is the Release Artist: the artist the metadata source attributes a Release to. This is a slippery thing to pin down: naming, stylization, collaborations, and user preferences all contribute to ambiguity about what counts as "the" artist.
Consider how many ways the same person can appear:
Each Release belongs to exactly one Artist. To add a Release in Lidarr, find the canonical Artist as the metadata source defines it. This isn't necessarily the name on the album cover. It's the name in MusicBrainz. This is the source of most "why can't I add this artist?" problems. See the FAQ for specific cases.
You can only manage
Release Artistsin Lidarr if they exist in third-party services.
The metadata source Lidarr relies on is MusicBrainz, a free, community-driven service that exists and survives on user contributions. Lidarr doesn't have its own metadata. It reads MusicBrainz's.
Two practical consequences follow.
Missing or incorrect data is a MusicBrainz problem, not a Lidarr problem. If an album isn't showing up in Lidarr, the first question to ask is whether it exists on MusicBrainz and whether the data there's correct. Lidarr doesn't offer a way to edit metadata locally. It reads MusicBrainz and doesn't override it. Fixes have to happen upstream at MusicBrainz, and Lidarr picks them up on the next refresh after propagation.
Propagation takes time. When someone adds or corrects a record on MusicBrainz, Lidarr doesn't see it immediately. Updates flow from MusicBrainz through a periodic sync into a metadata service that Lidarr queries, and from there into your instance on refresh. You can refresh individual artists and albums inside Lidarr once the upstream propagation has happened, but you can't speed up the propagation itself. Expect a delay measured in hours to days, not minutes.
If you find that a Release or Release Artist is missing from MusicBrainz, you can help fix it: see How To Contribute. Creating and editing MusicBrainz records is beyond the scope of this wiki.
Two questions that come up often enough to answer here:
Both are expected with the default Lidarr workflow, and both are answered by understanding how the post-import handoff works.
lidarr-music or similar, configurable per download client).If the download folder and the library folder are on the same filesystem (same mount, same partition), Lidarr uses a hardlink instead of a copy. A hardlink is a second directory entry pointing at the same underlying file. The file appears in both folders but only occupies disk space once. Lidarr can import by hardlink before the torrent finishes seeding, and seeding continues to work on the original file because they are literally the same bytes on disk.
If the download folder and the library folder are on different filesystems, Lidarr can't hardlink across them and falls back to a copy. The copy doubles the disk space until the download client cleans up its side.
The requirement for hardlinks to work:
Hardlinks are enabled by default. If you are seeing double disk usage, the usual culprits are mismatched mounts (Docker), a download client writing to a different filesystem than the library, or a filesystem that doesn't support hardlinks (some network filesystems, FAT32).
Lidarr is built around the Release model. If your library doesn't fit that model, Lidarr will be a frustrating tool no matter how much you tune it. Lidarr isn't a good fit for the following situations.
Releases sharing a single folder. Low-to-no-curation libraries won't work with Lidarr. Don't try.Release metadata on MusicBrainz is often missing or incorrect. You can use Lidarr, but expect substantial manual work.Releases in MusicBrainz. Third-party data sources return no metadata for them, so they can't be automated.Releases in the metadata sources and Lidarr can't manage them. This does not apply to albums in the Electronic genre, which are fine.If most of your library falls into one of the above categories, Lidarr may not be the right tool. If only part of your library does, you can still use Lidarr for the rest. Just expect to manage the problematic portion by hand.
The tools below can be used instead of, or alongside, Lidarr.
Using these in tandem with Lidarr is beyond the scope of this page, but they're common companions for preparing a library before import, or for managing the parts of a collection Lidarr can't.