Lidarr

Music collection manager and download automation tool

Media Servers ★ 5.7k stars Medium setup GPL-3.0

Lidarr is the music collection manager for the *arr suite, automating searches and downloads for your favorite artists. It monitors releases and integrates with download clients and media servers.

Key features

  • Automated music collection management
  • Release monitoring
  • Download client integration
  • Quality profiles

Pros & cons

Strengths

  • Part of the popular *arr suite
  • Strong automation

Trade-offs

  • Metadata accuracy varies
  • Companion to a media server

Lidarr replaces

Last reviewed Sep 13, 2026 · 838 words

Set your expectations before installing Lidarr: it is the least satisfying member of the *arr suite, and that is not the code's fault. TV and film have a handful of canonical releases per title and indexers that carry nearly everything; music has dozens of editions per album, a metadata database that Lidarr proxies through its own service, and indexer coverage that thins out fast outside the top 5,000 artists. It still automates the tedious part well, monitoring artists and grabbing new releases into a tidy library on 512 MB of RAM, but nobody's music collection ends up 100 percent green the way a TV library does.

Where it sits in the stack

Lidarr does not play music and does not download it. Prowlarr feeds it indexers; a download client such as qBittorrent or SABnzbd fetches the files; Lidarr renames and moves them into /data/media/music/Artist/Album/; a player such as Navidrome or Jellyfin serves the result. The arr stack explained post covers the shared plumbing, and every bit of it applies here. If you already run Sonarr and Radarr, Lidarr adds one more container and one more root folder and the setup is muscle memory.

The container is lscr.io/linuxserver/lidarr on port 8686. Use one /data bind mount shared with the download client so hardlinks work and imports are instant; split mounts mean every album is copied, and a lossless library is big enough for that to hurt.

services:
  lidarr:
    image: lscr.io/linuxserver/lidarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
    volumes:
      - ./config:/config
      - /srv/data:/data
    ports:
      - "8686:8686"
    restart: unless-stopped

Metadata is the weak point, and MusicBrainz is why

Lidarr identifies artists and albums using MusicBrainz data served through Lidarr's own metadata API. MusicBrainz is excellent for well-known artists and inconsistent for the long tail: an obscure band may exist with the wrong release group, a single "album" may be five editions with different track counts, and the metadata server itself has had outages that stop Lidarr from adding artists at all. When an import fails with "no matching release," the fix is usually to pick the right release under the album's edit menu, and sometimes to fix the entry on MusicBrainz itself. Budget for that if your taste runs deep.

Quality profiles are the other setting that decides your experience. A profile that accepts FLAC and MP3-320 with FLAC as the upgrade target gets you a library that fills in fast and improves over time; a FLAC-only profile on anything but mainstream releases mostly gets you a wanted list. Metadata profiles let you exclude live albums, singles and compilations, and I turn all three off on day one because the default of "grab everything" triples the wanted count with things I will never play.

Pair it with Beets for tags, and know the Soulseek gap

Lidarr writes basic tags and fetches cover art, but the tagging is not what a curated library wants. Beets run as a post-import step, or periodically over the library, fixes track numbers, genres, release dates and album artist consistency against MusicBrainz and Discogs, and the combination is what most serious collectors run. Navidrome then indexes the result cleanly.

The gap everyone hits is Soulseek. A large share of what is not on Usenet or public torrent trackers is on Soulseek, and stock Lidarr has no idea it exists. Community plugin builds of Lidarr add a slskd download client and indexer, and they work, but they are forks tracking a moving target. It is the main reason Lidarr users end up with a manual workflow alongside the automated one.

What automation you actually get

Once artists are monitored, Lidarr watches for new releases, grabs them on release day, upgrades existing albums when a better-quality copy appears, renames files to your pattern, and notifies Navidrome, Plex or Jellyfin to rescan. The calendar view shows upcoming releases for everything you follow, which is genuinely the feature I use most. Lists let you import artists from Spotify playlists, Last.fm or a text file, so a Spotify library becomes a monitored list in an afternoon. What you do not get is discovery; Lidarr only fetches what you told it to want.

What I'd do

Run Lidarr if you already have the *arr plumbing, a lossless-or-MP3-320 profile, and mainstream-to-moderately-obscure taste, and pair it with Beets and Navidrome from the start. Turn off singles and compilations in the metadata profile, expect to hand-pick releases for a tenth of your artists, and keep a manual slskd workflow for the rest. If your library is mostly rare or regional music, Lidarr will frustrate you more than it helps; use Beets plus slskd directly and skip the automation. Either way, Navidrome is the part of this stack you will actually see every day, so set it up first and let Lidarr feed it.

Compare Lidarr

21 head-to-head comparisons.

Similar media servers apps