docs: consolidate community PRs and resolve grounded issues

CONTRIBUTING.md

@@ -83,7 +83,7 @@ Controls markdown linting rules. Key settings:
 
 - `MD013: false` - No line length limit
 - `MD033: {...}` - Allow specific HTML elements
-- `MD024: { "siblings_only": true }` - Allow duplicate headers only if not siblings
+- `MD024: false` - Allow duplicate headers
 - `MD046: { "style": "fenced" }` - Use fenced code blocks
 
 ### `.typos.toml`
@@ -102,9 +102,9 @@ Defines all the hooks and their configuration.
 
 The repository includes GitHub Actions workflows that run the same checks:
 
-- **quality-checks.yml**: Runs pre-commit hooks on pull requests
-- Separate jobs for markdown linting and spell checking
-- Caches dependencies for faster builds
+- **pre-commit.yml**: Runs all pre-commit hooks (markdown linting, spell checking, formatting) on pushes and pull requests to `master`/`main`
+- A single `documentation-quality` job runs the full hook suite via `pre-commit/action`
+- Caches pre-commit environments and pip dependencies for faster builds
 
 ## Contributing Guidelines
 

README.md

@@ -25,5 +25,5 @@ Feel free to contribute directly on the wiki or via Github Pull Requests.
 Please ensure to markdown is formatted properly.
 
 - Install Markdownlint `npm install -g markdownlint-cli`
-- Run the linting to attempt to fix issues. `markdownlint -f '**/*.md' -c .markdownlint.jsonc`
+- Run the linting to attempt to fix issues. `markdownlint -f '**/*.md' -c .markdownlint.json`
   - Note any errors and correct them. This command should be ran from your local repo.

docker-arm-synology.md

@@ -3,11 +3,13 @@ title: Installing Docker on a Synology ARM NAS
 description: Step-by-step guide for installing Docker on ARM-based Synology NAS devices and running Servarr applications
 published: true
 date: 2022-05-18T15:47:17.201Z
-tags: docker, synology, arm, installation, nas
+tags: docker, synology, arm, installation, nas, deprecated
 editor: markdown
 dateCreated: 2021-07-12T20:22:05.719Z
 ---
 
+> **This guide is outdated and deprecated.** It dates from 2021 and relies on an unmaintained third-party bootstrap that installs Docker 20.10.0 and Docker Compose v1 (`docker-compose`). It has not been validated against current DSM releases and may no longer work. Prefer Synology's official Container Manager on supported hardware; use this only if you understand the risks. {.is-warning}
+
 # Introduction
 
 Synology only offer a Docker package on their `x64` based NAS. Using this method to install Docker on an `aarch64` NAS is totally unsupported/untested and totally at your own risk. It is entirely possible it will destroy your NAS.

lidarr/activity.md

@@ -44,9 +44,15 @@ Each row has action icons on the right:
 
 - **Manual Import** (person icon): opens the manual import dialog for this item, letting you match and import it yourself.
 - **Grab** (download icon): re-sends the release to the download client. Useful if the client removed an item that's still in the Lidarr queue.
-- **Remove** (✕): removes the item from the Lidarr queue. When removing, you can also choose to:
-  - **Remove from Download Client:** deletes the item from the download client as well. Use this for unmatched items Lidarr shouldn't download.
-  - **Add to Blocklist:** prevents Lidarr from grabbing this release again.
+- **Remove** (✕): opens the Remove dialog, where you choose a **Removal Method** and a **Blocklist Method**.
+  - Removal Method:
+    - **Remove from Download Client:** deletes the item from the download client as well. Use this for unmatched items Lidarr shouldn't download.
+    - **Change Category:** moves the item to the download client's post-import category instead of deleting it (only available when a post-import category is configured).
+    - **Ignore Download:** leaves the item in the download client but stops Lidarr from processing it any further.
+  - Blocklist Method:
+    - **Do Not Blocklist:** removes the item without blocklisting the release.
+    - **Blocklist and Search:** blocklists the release and triggers a new search for a replacement.
+    - **Blocklist Only:** blocklists the release without searching for a replacement.
 
 ### Queue options
 

lidarr/beets-integration.md

@@ -33,11 +33,11 @@ Platform notes:
 
 Both patterns require that Lidarr doesn't overwrite tags after beets has written them. Set this before configuring either pattern:
 
-**Settings → Metadata → Write Audio Tags → Write Tags: Never**
+**Settings → Metadata → Write Metadata to Audio Files → Tag Audio Files with Metadata: Never**
 
 With this set, Lidarr won't write or rewrite audio file tags at any point. Beets becomes the sole tag writer. Lidarr continues to manage file names and folder structure via its naming templates. Lidarr delegates only tag content to beets.
 
-> If you had **Write Tags** set to anything other than **Never**, consider running a beets pass over your existing library after changing this setting, since Lidarr tagged those files and they may have gaps that beets can fill.
+> If you had **Tag Audio Files with Metadata** set to anything other than **Never** (the other options are *For new downloads only*, *All files; initial import only*, and *All files; keep in sync with MusicBrainz*), consider running a beets pass over your existing library after changing this setting, since Lidarr tagged those files and they may have gaps that beets can fill.
 {.is-info}
 
 # Pattern 1: Import script (stateless, per-import)
@@ -138,7 +138,7 @@ foreach ($dir in $albumDirs) {
 | **Benefit** | beets runs once at import time with any plugins you want, writing a full tag set that Lidarr wouldn't produce on its own. |
 | **Benefit** | No persistent beets database to maintain or back up. |
 | **Drawback** | Tags written at import time are never updated. If MusicBrainz data improves, or a plugin source updates its data (for example, updated ReplayGain values), the library files won't reflect it until you re-import or run beets manually. |
-| **Drawback** | Lidarr's **Write Tags: Never** setting means files you imported before configuring beets won't have their tags updated automatically. Run a manual beets pass to backfill those. |
+| **Drawback** | Lidarr's **Tag Audio Files with Metadata: Never** setting means files you imported before configuring beets won't have their tags updated automatically. Run a manual beets pass to backfill those. |
 
 # Pattern 2: Side-by-side persistent beets
 
@@ -184,7 +184,7 @@ Two scenarios where the tools can conflict:
 
 **Lidarr renames files after beets has tagged them.** When Lidarr renames a file (for example, because you change a naming template), the file path changes but the tags beets wrote remain. beets' persistent database will have the old path and will treat the file as missing. Resolution: after a Lidarr rename, run `beet update` to resync the beets database to the new paths, then a `beet import` pass if you want to re-enrich the renamed files.
 
-**Metadata refresh.** Lidarr periodically refreshes artist metadata from MusicBrainz and can overwrite file tags if Write Tags isn't set to Never. With **Write Tags: Never** set as described above, this doesn't occur.
+**Metadata refresh.** Lidarr periodically refreshes artist metadata from MusicBrainz and can overwrite file tags if **Tag Audio Files with Metadata** isn't set to Never. With **Tag Audio Files with Metadata: Never** set as described above, this doesn't occur.
 
 ## Trade-offs
 
@@ -199,6 +199,6 @@ Two scenarios where the tools can conflict:
 # See also
 
 - [Custom Scripts](/lidarr/custom-scripts): environment variables available to scripts and how to register them
-- [Settings: Metadata](/lidarr/settings#metadata): Write Tags setting and metadata consumer options
+- [Settings](/lidarr/settings): the **Tag Audio Files with Metadata** option lives under Settings → Metadata
 - [beets documentation](https://beets.readthedocs.io/en/stable/)
 - [beets installation guide](https://beets.readthedocs.io/en/stable/guides/installation.html)

lidarr/community-guide.md

@@ -13,5 +13,5 @@ This guide's content now lives in these wiki pages:
 
 - **Naming** → [Naming Guide](/lidarr/naming-guide)
 - **Custom Formats and profile scoring** → [Custom Formats](/lidarr/tips-and-tricks#custom-formats)
-- **Quality and metadata profile configuration** → [Settings: Profiles](/lidarr/settings#profiles)
-- **Tag writing and hardlink considerations** → [Settings: Metadata](/lidarr/settings#metadata)
+- **Quality and metadata profile configuration** → [Settings: Metadata Profiles](/lidarr/settings#metadata-profiles)
+- **Tag writing and hardlink considerations** → [Settings: File Management](/lidarr/settings#file-management)

lidarr/concepts.md

@@ -97,3 +97,16 @@ If you find that a `Release` or `Release Artist` is missing from MusicBrainz, yo
 Two questions that come up often enough to answer here:
 
 - *Why do I have the same file in my download folder and my library folder?*
+- *Why did importing fill up my disk?*
+
+When Lidarr imports a completed download, it doesn't move the file out of the download client's folder by default. The download usually needs to stay there so your torrent client can keep seeding. Instead, Lidarr puts a copy of each track into your library folder and leaves the original where the client downloaded it.
+
+How that copy is made depends on where the two folders live:
+
+- **Same filesystem → hardlink.** A hardlink is a second name for the *same* data on disk. The file appears in both your download folder and your library folder, but it only occupies the space once. Seeding continues uninterrupted because the bytes never move. This is the default and the reason both paths must be on the same volume.
+- **Different filesystems → copy.** Hardlinks can't span filesystems, so Lidarr falls back to copying the data. Now the bytes exist twice, which uses the extra disk space and the extra I/O. This is the usual cause of "importing filled up my disk."
+
+The behavior is controlled by **Use Hardlinks instead of Copy** under *Settings → Media Management* (an advanced setting, enabled by default). When it's on, Lidarr hardlinks where it can and copies where it can't; when it's off, Lidarr always copies. Disk-layout mistakes are by far the most common cause of unexpected copying — in Docker, the download folder and the library root must be reachable through the *same* volume mount for hardlinks to work.
+
+> Hardlinks only work when the source and destination are on the same filesystem. If your download folder and library folder are on different drives, volumes, or Docker mounts, Lidarr copies instead — using twice the space. See [TRaSH's Hardlink Guide](https://trash-guides.info/hardlinks) for setup details.
+{.is-info}

lidarr/faq.md

@@ -131,7 +131,7 @@ Imports fail in one of a few ways:
 - **The download finished but Lidarr won't import it.** This is almost always a match-quality rejection. Lidarr couldn't find a MusicBrainz release that resembles the file well enough. See [Import Troubleshooting](/lidarr/import-troubleshooting) for the match-quality rules, the fingerprinting fallback, when manual import is the expected path, and how to drive it.
 - **You're importing an existing library and the match fails.** See [Importing an Existing Library](/lidarr/importing-existing-library) for the fresh-install walkthrough and the lenience rules that apply to library imports.
 - **Lidarr can't read or write the folder.** The user account Lidarr runs as must have read and write access to both the download folder and the destination root folder. On Linux this is a UID/GID/permissions issue on a mount; on Windows it's Lidarr running as `LocalService` which can't reach a network share. See [Why can't Lidarr see my files on a remote server?](#why-cant-lidarr-see-my-files-on-a-remote-server) for the Windows case.
-- **Untagged or badly tagged files.** Files with generic filenames like `track01.mp3` and no tags give Lidarr nothing to match on. Run a tagger such as [MusicBrainz Picard](https://picard.musicbrainz.org/) or [Harmony](https://harmony.pulsewidth.org.uk/) before importing. See [Import Troubleshooting → Untagged or badly tagged files](/lidarr/import-troubleshooting#untagged-or-badly tagged-files).
+- **Untagged or badly tagged files.** Files with generic filenames like `track01.mp3` and no tags give Lidarr nothing to match on. Run a tagger such as [MusicBrainz Picard](https://picard.musicbrainz.org/) or [Harmony](https://harmony.pulsewidth.org.uk/) before importing. See [Import Troubleshooting → Untagged or badly tagged files](/lidarr/import-troubleshooting#untagged-or-badly-tagged-files).
 
 ### I copied files into Lidarr's root folder but Lidarr can't see them
 
@@ -294,7 +294,7 @@ As of Lidarr v2, **authentication is mandatory.** The config file must include `
 
 #### Authentication Required
 
-If the UI only needs auth on remote access (not on LAN), set **Settings → General → Security → Authentication Required** to *Disabled For Local Addresses*. In the config file that's `<AuthenticationType>DisabledForLocalAddresses</AuthenticationType>`. The other valid value is `Enabled`.
+If the UI only needs auth on remote access (not on LAN), set **Settings → General → Security → Authentication Required** to *Disabled For Local Addresses*. In the config file that's `<AuthenticationRequired>DisabledForLocalAddresses</AuthenticationRequired>`. The other valid value is `Enabled`.
 
 ### Help I have locked myself out
 

lidarr/installation/freebsd.md

@@ -8,7 +8,7 @@ editor: markdown
 dateCreated: 2023-07-03T20:10:42.484Z
 ---
 
-## FreeBSD
+# FreeBSD
 
 The Lidarr team only provides builds for FreeBSD. The FreeBSD community maintains Plugins and Ports.
 

lidarr/installation/reverse-proxy.md

@@ -19,7 +19,7 @@ Sample config examples for configuring Lidarr to be accessible through a reverse
 
 Add the following configuration to `nginx.conf` in the root of your Nginx configuration. Place the code block inside the `server` context. [Full example of a typical Nginx configuration](https://www.nginx.com/resources/wiki/start/topics/examples/full/)
 
-> If you're using a non-standard http/https server port, make sure your Host header also includes it, for example: `proxy_set_header Host $host:$server_port` or `proxy_set_header Host $http_host`
+> If you're using a non-standard http/https server port, make sure your `X-Forwarded-Host` header also includes it, for example: `proxy_set_header X-Forwarded-Host $host:$server_port` or `proxy_set_header X-Forwarded-Host $http_host`
 {.is-warning}
 
 ```nginx
@@ -68,7 +68,7 @@ Nginx includes the `sites-enabled` folder by default. Check `nginx.conf` and add
 > For subdomain configuration, set baseurl to `''` (empty). This assumes the default port `8686` and Lidarr on localhost (127.0.0.1). Line 5 sets the subdomain to `lidarr`.
 {.is-info}
 
-> If you're using a non-standard http/https server port, make sure your Host header also includes it, for example: `proxy_set_header Host $host:$server_port` or `proxy_set_header Host $http_host`
+> If you're using a non-standard http/https server port, make sure your `X-Forwarded-Host` header also includes it, for example: `proxy_set_header X-Forwarded-Host $host:$server_port` or `proxy_set_header X-Forwarded-Host $http_host`
 {.is-warning}
 
 ```nginx

lidarr/naming-guide.md

@@ -145,7 +145,7 @@ From Davo's [community guide](/lidarr/community-guide). Puts the album folder in
 
 ## B's convention
 
-Limits folder and file lengths to avoid Windows path-limit issues. **Not recommended for Windows**: the truncated paths can become inaccessible after a Lidarr rename on that OS. See the [FAQ entry on Windows folder access after rename](/lidarr/faq#why-cant-i-access-a-folder-in-windows-after-lidarr-rename). Useful for libraries containing artists with notoriously long album titles.
+Limits folder and file lengths to avoid Windows path-limit issues. **Not recommended for Windows**: the truncated paths can become inaccessible after a Lidarr rename on that OS. See [OS path limits and illegal characters](#os-path-limits-and-illegal-characters) above. Useful for libraries containing artists with notoriously long album titles.
 
 ### Standard Track Format
 

lidarr/settings.md

@@ -37,7 +37,7 @@ When **Replace Illegal Characters** is enabled, controls how Lidarr replaces col
 |---|---|
 | **Delete** | Removes the colon and any following space (`Artist:Name` → `ArtistName`). |
 | **Replace with Dash** | Replaces with a dash (`Artist:Name` → `Artist-Name`). |
-| **Replace with Space Dash** | Replaces with a space-dash (`Artist: Name` → `Artist -Name`). |
+| **Replace with Space Dash** | Replaces with a space-dash (`Artist:Name` → `Artist -Name`). |
 | **Replace with Space Dash Space** | Replaces with a space-dash-space (`Artist: Name` → `Artist - Name`). |
 | **Smart Replace** | Uses a dash when the colon isn't followed by a space, or a space-dash when it is (`Artist:Name` → `Artist-Name`; `Artist: Name` → `Artist - Name`). |
 
@@ -207,7 +207,7 @@ Common specification types for music:
 | **Release Title** | The full release title string from the indexer. Supports regex. |
 | **Release Group** | The release group part of the title, if parseable. |
 | **Indexer Flag** | Indexer-specific flags (Freeleech, Halfleech, etc.) where the indexer supports them. |
-| **Source** | Audio source tag (CD, WEB, Vinyl, etc.) if present in the title. |
+| **Size** | The reported release size. Matches when the size falls between the configured **Minimum Size** and **Maximum Size** (in GB). |
 
 For worked examples and suggested scoring values for a FLAC-focused library, see [Tips and Tricks → Custom Formats](/lidarr/tips-and-tricks#custom-formats).
 

lidarr/system.md

@@ -185,7 +185,7 @@ sudo systemctl start $app
 
 #### Can’t install update because startup folder is in an App Translocation folder (macOS)
 
-{#cannot-install-update-because-startup-folder-is-in-an-app-translocation-folder.}
+{#cannot-install-update-because-startup-folder-is-in-an-app-translocation-folder-macos}
 
 - macOS has moved Lidarr’s startup folder into an App Translocation path. This prevents Lidarr from updating itself. Remove the quarantine attribute or move Lidarr out of the Translocation folder and re-launch it from its permanent location.
 
@@ -292,7 +292,7 @@ RewriteRule /(.*) ws://127.0.0.1:8686/$1 [P,L]
 
 {#fpcalc-upgrade}
 
-- Lidarr uses chromaprint audio fingerprinting to identify tracks. This depends on an external binary `fpcalc`. Lidarr v1 ships `fpcalc` for Windows, Linux, and macOS, but freeBSD requires you to provide it separately.
+- Lidarr uses chromaprint audio fingerprinting to identify tracks. This depends on an external binary `fpcalc`. The installed `fpcalc` is too old; Lidarr requires at least version 1.4.3. Lidarr v1 ships `fpcalc` for Windows, Linux, and macOS, but freeBSD requires you to provide it separately.
 - Ensure the fpcalc binary bundled with Lidarr is executable (755 permissions). Look for it in Lidarr's installation directory (for example `/opt/Lidarr/fpcalc`). If it isn't executable, correct its permissions with the command below and restart Lidarr.
   - Note that the fix may need `sudo`, and your path to Lidarr's binary folder may differ depending on your environment.