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.
Lidarr requires that your download folder and your music library root folder aren't the same location. This isn't just a best practice — mixing them causes imports to fail or loop, since Lidarr can't reliably tell what's a finished download and what's already part of the library.
A clean layout keeps three locations separate:
/data/
downloads/ ← download client writes here
music/ ← Lidarr root folder (your library)
Lidarr moves (or hardlinks) files from downloads/ into music/ on import. Once imported, the file in downloads/ is the copy the download client owns; the file in music/ is the copy 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 run more than one download client (for example, both a Usenet client and a torrent client), give each its own download subfolder and configure 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 set the Download Client's own category to match. Lidarr only monitors items in the configured category — anything outside it's invisible, which prevents cross-contamination between clients and between applications sharing the same client.
Radarr, Sonarr, and Lidarr can share the same download client safely 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.
If Lidarr and your download client run in separate containers or on separate machines, the path the download client reports for a completed download may differ from the path Lidarr sees when it tries to access the same file. Use Settings → Download Clients → Remote Path Mappings to translate between the two. See Troubleshooting → Remote Path Mapping for the full explanation.
Artist images in Lidarr are pulled 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 an obviously-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.
Album cover art is sourced from MusicBrainz's Cover Art Archive via the Servarr metadata server.
Covers uploaded directly to the Cover Art Archive are available to Lidarr faster than other metadata corrections, because CAA has a more direct path into the metadata server than the 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, which present as a single very large track rather than properly split files.
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" }
}
]
}
Once the formats are created, 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 to be grabbed — releases with no recognised source tag are skipped 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 you the same parser output. Use them when writing a custom format specification, debugging a release that isn't scoring as expected, or confirming that a release group pattern matches before adding it to a release profile.
Lidarr's entire state lives in its AppData directory. Backing up is a matter of capturing that directory at rest; restoring is a matter of 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 the minimum 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 — usually /usr/local/Lidarr/var/.config/Lidarr/.
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 what the existing files are owned by before the restore if you aren't sure.
Start Lidarr.