Recipes and workarounds for things that come up often enough to be worth documenting, but don't fit the install / troubleshoot / FAQ shape. Most of this is library-management content: filling in gaps in metadata, bulk-editing the library, and backup/restore hygiene.
For setup recipes (reverse proxy, VPN, Docker compose, hardlinks) see the TRaSH Guides — they cover those topics in more depth than this wiki does.
Your download folder and music library root folder can't be the same location. Mixing them causes imports to fail or loop — Lidarr can't tell a finished download from something already in the library.
Keep two locations separate:
/data/
downloads/ ← download client writes here
music/ ← Lidarr root folder (your library)
On import, Lidarr moves (or hardlinks) files from downloads/ into music/. The copy in downloads/ stays owned by the download client. The copy in music/ is what Lidarr manages.
For hardlinks to work — which avoids any extra disk space during import — both paths must be on the same physical filesystem. If
downloads/andmusic/are on different drives or volumes, Lidarr will copy instead of hardlink. See Concepts → Hardlinks and completed downloads.
If you're running more than one download client — say, a Usenet client alongside a torrent client — give each its own subfolder under downloads/ and set a matching category in Lidarr:
/data/
downloads/
usenet/ ← SABnzbd / NZBGet category: "lidarr"
torrents/ ← qBittorrent / Deluge category: "lidarr"
music/
In Settings → Download Clients, set each client's Category to a unique value (for example, lidarr) and make sure the download client itself uses the same category name. Lidarr only watches items in the configured category — anything outside it's invisible. This keeps clients from stepping on each other and prevents apps that share a client from grabbing each other's downloads.
Radarr, Sonarr, and Lidarr can share the same download client as long as each application uses a different category. Never point two applications at the same category — they will fight over each other's downloads.
Why
downloads/instead of TRaSH's flat layout? TRaSH Guides placestorrents/andusenet/as peer directories next tomedia/at the top level. This layout groups them under a singledownloads/parent instead. The reason is that Lidarr's ecosystem tends to involve more download sources than just torrents and Usenet — slskd, deemix, manual imports, and others are all common additions. Grouping them keeps the top level clean as that list grows. The TRaSH principle that actually matters — keeping everything under one filesystem root so hardlinks work — hasn't changed. See this r/Lidarr post for a fuller breakdown.
When Lidarr and your download client run in separate containers or machines, the path the client reports may not match what Lidarr sees. Use Settings → Download Clients → Remote Path Mappings to translate between the two. See Troubleshooting → Remote Path Mapping for the full explanation.
Lidarr pulls artist images from whatever the Servarr metadata server aggregates from its upstream sources. Lidarr itself doesn't reach out to any specific image service — it renders whatever URLs the metadata server returns.
If an artist is showing no image or a wrong image:
Lidarr has no "upload an image locally" option. Everything it displays has to exist upstream. This is the same model as the Release / Release Artist data itself — see Concepts.
Lidarr pulls album cover art from MusicBrainz's Cover Art Archive via the Servarr metadata server.
Lidarr picks up covers uploaded directly to the Cover Art Archive faster than other metadata corrections. CAA has a more direct path into the metadata server than MusicBrainz entity data does.
Use Library → Artist Editor (formerly "Mass Editor"):
The same flow works for bulk changes that aren't deletion — root folder moves, quality profile swaps, monitoring toggles — via the other bulk-action buttons at the bottom of Artist Editor.
Custom formats let you score releases by source, release group, and other title characteristics so Lidarr can prefer or avoid them automatically. The examples below are a useful starting point for a FLAC-focused library. Import each block via Settings → Custom Formats → Import.
Before setting up custom format scoring, consider tightening the FLAC quality definition to filter out single-file CUE+FLAC rips. These present as one large file rather than individually split tracks.
In Settings → Quality, set the FLAC row to:
| Min | Preferred | Max | |
|---|---|---|---|
| FLAC | 0 | 895 | 1400 |
| FLAC 24bit | 0 | 895 | 1495 |
The Max value rejects releases whose computed bitrate exceeds a realistic ceiling for split-track FLAC, which catches most CUE+single-file rips without affecting normal releases.
Boosts releases from groups known for consistent quality and accurate tagging.
{
"name": "Preferred Groups",
"includeCustomFormatWhenRenaming": false,
"specifications": [
{
"name": "DeVOiD",
"implementation": "ReleaseGroupSpecification",
"negate": false,
"required": false,
"fields": { "value": "\\bDeVOiD\\b" }
},
{
"name": "PERFECT",
"implementation": "ReleaseGroupSpecification",
"negate": false,
"required": false,
"fields": { "value": "\\bPERFECT\\b" }
},
{
"name": "ENRiCH",
"implementation": "ReleaseGroupSpecification",
"negate": false,
"required": false,
"fields": { "value": "\\bENRiCH\\b" }
}
]
}
Tags releases identified as a CD source.
{
"name": "CD",
"includeCustomFormatWhenRenaming": false,
"specifications": [
{
"name": "CD",
"implementation": "ReleaseTitleSpecification",
"negate": false,
"required": false,
"fields": { "value": "\\bCD\\b" }
}
]
}
Tags releases identified as a web (streaming) source.
{
"name": "WEB",
"includeCustomFormatWhenRenaming": false,
"specifications": [
{
"name": "WEB",
"implementation": "ReleaseTitleSpecification",
"negate": false,
"required": false,
"fields": { "value": "\\bWEB\\b" }
}
]
}
Tags releases that identify themselves as lossless. Useful on Usenet where filenames are less predictable.
{
"name": "Lossless",
"includeCustomFormatWhenRenaming": false,
"specifications": [
{
"name": "Lossless",
"implementation": "ReleaseTitleSpecification",
"negate": false,
"required": false,
"fields": { "value": "\\blossless\\b" }
}
]
}
Tags releases from a vinyl source, for libraries that want to avoid or specifically seek out vinyl rips.
{
"name": "Vinyl",
"includeCustomFormatWhenRenaming": false,
"specifications": [
{
"name": "Vinyl",
"implementation": "ReleaseTitleSpecification",
"negate": false,
"required": false,
"fields": { "value": "\\bVinyl\\b" }
}
]
}
After creating the formats, assign scores in Settings → Profiles → [your profile] → Custom Formats. The table below implements a setup that requires releases to match at least one positive format before Lidarr will grab them, prefers CD over WEB, and actively avoids vinyl.
| Custom Format | Score |
|---|---|
| Preferred Groups | 100 |
| CD | 10 |
| Lossless | 10 |
| WEB | 5 |
| Vinyl | -10000 |
Set Minimum Custom Format Score to 1 in the profile. This means a release must match at least one of CD, Lossless, WEB, or Preferred Groups before Lidarr will grab it — Lidarr skips releases with no recognised source tag entirely.
Scoring is subjective and depends on your indexers and sources. Treat these values as a starting point, not a prescription.
Two ways to check how Lidarr will parse a release name before building profiles around it:
In Lidarr: Go to Settings → Custom Formats and use the Test Parsing button. Enter a release title and Lidarr shows the parsed fields (source, quality, release group, etc.) alongside which custom formats match and their combined score.
Via the Servarr Discord bot: In the #bot-spam channel on the Servarr Discord, run /parser lidarr <release title> — for example, /parser lidarr Artist.Album.2022.FLAC-GROUP. The bot replies with the same parsed breakdown. Any user who donates to Servarr becomes a Donatarr and can use the parser bot.
Both tools give the same parser output. Use either when writing a custom format specification, debugging a release that isn't scoring as expected, or confirming a release group pattern matches before adding it to a profile.
Lidarr's entire state lives in its AppData directory. Backing up means capturing that directory at rest. Restoring means putting it back in place with matching permissions and paths. There's nothing in the database that's meaningful without the matching config.xml and vice-versa — back up the whole folder, not individual files.
Two ways to do it. Use whichever fits your workflow.
Built-in backup (zip):
This captures the database, config, and everything needed to restore. The backup excludes the logs folder and the MediaCover cache, both of which are regenerable.
Filesystem copy:
.db-wal and .db-journal siblings of lidarr.db if they exist.Filesystem backup is the right choice if you want to use existing backup tooling (Borg, restic, Duplicati, ZFS snapshots, etc.) — don't try to snapshot a live SQLite file.
Cross-OS restores aren't supported. Windows ↔ Linux and Windows ↔ macOS won't work because the path separators differ. Linux ↔ macOS may work since both use
/, but isn't officially supported. If you need to move between OSes, expect to edit every path in the database by hand.
From a built-in zip backup:
From a filesystem copy:
.db-wal / .db-journal files.As long as the root folder paths in the backup are still valid on the destination machine, Lidarr will pick up where it left off.
CAUTION: this procedure requires root SSH access and is unnecessary on most systems. Use it only if the standard filesystem restore fails due to Synology's package-user permissions model.
Install Lidarr via the SPK package if it isn't installed.
Find the AppData directory — /usr/local/Lidarr/var/.config/Lidarr/ by default.
Stop Lidarr.
SSH to the NAS as root.
Replace the database and restore:
rm -r /usr/local/Lidarr/var/.config/Lidarr/Lidarr.db
cp -f /tmp/Lidarr_backup/* /usr/local/Lidarr/var/.config/Lidarr/
Fix ownership and permissions:
cd /usr/local/Lidarr/var/.config/Lidarr/
chown -R Lidarr:users *
chmod -R 0644 *
On some SynoCommunity versions the user is
sc-Lidarrrather thanLidarr—chown -R sc-Lidarr:Lidarr *. Check who owns the existing files before the restore if you aren't sure.
Start Lidarr.