This page lists health check results. Lidarr runs these checks periodically and on certain events, and lists any warnings or errors here with advice on how to resolve them.
The branch you have set isn't a valid release branch. You won't receive updates. Please change to one of the current release branches.
- Newer versions of Lidarr target .NET6 or newer. Legacy mono builds end after the 1.0 release. You are running one of these legacy builds but your platform supports .NET.
¶ Fixing Standalone installs
- Back-Up your existing configuration before the next step.
- This should only happen on Linux hosts. Don't install .NET runtime or SDK from Microsoft.
- To remedy, download the correct build for your architecture and replace your existing binaries (application)
- In short you will need to delete your existing binaries (contents or folder of /opt/Lidarr) and replace with the contents of the .tar.gz you just downloaded.
DON'T JUST EXTRACT THE DOWNLOAD OVER THE TOP OF YOUR EXISTING BINARIES.
YOU MUST DELETE THE OLD ONES FIRST.
- The below is a community developed script to remove your mono installation and replace it with the .NET installation. Contributions and corrections are welcome.
- This assumes you are on the
master Lidarr branch update the variable if needed
- This assumes that Lidarr runs as the user
lidarr update the variables if needed
- This assumes you installed Lidarr at
/opt/Lidarr; update the variables if needed
#!/bin/bash
## User Variables
installdir="/opt/Lidarr"
APPUSER="lidarr"
branch="master"
## /User Variables
app="lidarr"
ARCH=$(dpkg --print-architecture)
# Stop \*arr
sudo systemctl stop $app
# get arch
dlbase="https://$app.servarr.com/v1/update/$branch/updatefile?os=linux&runtime=netcore"
case "$ARCH" in
"amd64") DLURL="${dlbase}&arch=x64" ;;
"armhf") DLURL="${dlbase}&arch=arm" ;;
"arm64") DLURL="${dlbase}&arch=arm64" ;;
*)
echo_error "Arch not supported"
exit 1
;;
esac
echo "Downloading..."
wget --content-disposition "$DLURL"
tar -xvzf ${app^}.*.tar.gz
echo "Installation files downloaded and extracted"
echo "Moving existing installation"
sudo mv "$installdir/" "$installdir.old/"
echo "Installing..."
sudo mv "${app^}" "$installdir"
sudo chown $APPUSER:$APPUSER -R $installdir
sudo sed -i "s|ExecStart=/usr/bin/mono --debug /opt/${app^}/${app^}.exe|ExecStart=/opt/${app^}/${app^}|g" /etc/systemd/system/$app.service
sudo sed -i "s|ExecStart=/usr/bin/mono /opt/${app^}/${app^}.exe|ExecStart=/opt/${app^}/${app^}|g" /etc/systemd/system/$app.service
sudo systemctl daemon-reload
echo "App Installed"
sudo rm -rf "$installdir.old/"
rm -rf "${app^}.*.tar.gz"
sudo systemctl start $app
¶ Currently installed mono version is old and unsupported
- Lidarr uses .NET and requires Mono to run on very old ARM processors. Please note that Mono builds are no longer supported after v1.0
- Mono 5.20 is the absolute minimum for Lidarr.
- The upgrade procedure for Mono varies per platform.
- Lidarr stores its data in an SQLite database. The SQLite3 library installed on your system is too old. Lidarr requires at least version 3.9.0. Note that Lidarr uses
libSQLite3.so, which may not come with a SQLite3 upgrade package.
- A new version of Lidarr is available. If auto-updating is enabled, Lidarr will install it automatically. Otherwise, go to
System => Updates and press Install.
This warning won't appear if your current version is less than 14 days old.
- This means Lidarr will be unable to update itself. You’ll have to update Lidarr manually or set the permissions on Lidarr’s Startup directory (the installation directory) to allow Lidarr to update itself.
-
Lidarr detected that the AppData folder sits inside the directory that contains the Lidarr binaries. Normally it would be C:\ProgramData for Windows and ~/.config for Linux.
-
Please look at System => Info to see the current AppData & Startup directories.
-
This means Lidarr will be unable to update itself without risking data loss.
-
If you’re on linux, you’ll probably have to change the home directory for the user that's running Lidarr and copy the current contents of the ~/.config/Lidarr directory to preserve your database.
- The update branch setup in
Settings => General is for a previous version of Lidarr, therefore the instance won't see correct update information in the System => Updates feed and may not receive new updates when released.
-
signalR drives the dynamic UI updates, so if your browser can't connect to signalR on your server you won’t see any real time updates in the UI.
-
The most common occurrence of this is use of a reverse proxy or Cloudflare.
-
Cloudflare needs websockets enabled.
- Nginx requires the following addition to the location block for the app:
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
Make sure you don't include proxy_set_header Connection "Upgrade"; as suggested by the nginx documentation. THIS WON'T WORK
See https://github.com/aspnet/AspNetCore/issues/17081
- For Apache2 reverse proxy, you need to enable the following modules: proxy, proxy_http, and proxy_wstunnel. Then, add this websocket tunnel directive to your vhost configuration:
RewriteEngine On
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.*) ws://127.0.0.1:8686/$1 [P,L]
- For Caddy (V1) use this:
- Note: you will also need to add the websocket directive to your lidarr configuration
proxy /lidarr 127.0.0.1:8686 {
websocket
transparent
}
- Review your proxy settings and ensure they're accurate
- Ensure your proxy is up, running, and accessible
- Your configured proxy failed to test successfully, review the HTTP error provided and/or check logs for more details.
- System time is off by more than 1 day. Scheduled tasks may not run correctly until you correct the time
- Review your system time and ensure it's synced to an authoritative time server and accurate
- Mono 4.x tls workaround still enabled, consider removing
MONO_TLS_PROVIDER=legacy environment option
¶ Mono and x86 builds are ending
- The next build of the application won't support Mono or x86. If you are receiving this error then you are running the mono version of the application or the x86 version. Unfortunately, due to increasing difficulty in supporting these legacy versions, support and releases for them are discontinued. Upgrade to a supported operating system that doesn't require x86 or Mono. You may also be able to explore using Docker for your needs.
- 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.
- Ensure the fpcalc binary bundled with Lidarr is executable (755 permissions). Look for it in Lidarr's installation directory (e.g.
/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.
chmod +x /opt/Lidarr/fpcalc
The below information is for legacy v0.8.0 builds only.
- To fix this on a native Linux instance, install the appropriate package using your package manager and confirm that fpcalc is on your PATH by running
which fpcalc and checking that it returns the correct location:
| Distribution |
Package |
| Debian/Ubuntu |
libchromaprint-tools |
| Fedora/CentOS |
chromaprint-tools |
| Arch |
chromaprint |
| OpenSUSE |
chromaprint-fpcalc |
| Synology |
chromaprint |
- Lidarr needs a properly configured and enabled download client to download media. Since Lidarr supports different download clients, you should determine which best matches your requirements. If you already have a download client installed, you should configure Lidarr to use it and create a category. See
Settings=>Download Client.
- Lidarr was unable to communicate with the configured download client. Please verify the download client is operational and double-check the URL. This could also indicate an authentication error.
- This is typically due to improperly configured download client. Things you can typically check:
- Your download client's IP Address - if it's all on the same bare metal machine, this is typically
127.0.0.1
- The Port number that your download client is using - these default to the standard port number, but if you've changed it you will need to enter the same one in Lidarr.
- Ensure that SSL encryption isn't turned on if you're using both your Lidarr instance and your download client on a local network (that is, over plain HTTP). See the SSL FAQ entry for more information.
- One or more of your download clients isn't responding to requests made by Lidarr. Therefore Lidarr has decided to temporarily stop querying the download client on its normal 1-minute cycle, which is normally used to track active downloads and import finished ones. However, Lidarr will continue to attempt to send downloads to the client, but will likely fail.
- You should inspect
System=>Logs to see what the reason is for the failures.
- If you no longer use this download client, disable it in Lidarr to prevent the errors.
¶ Enable Completed Download Handling
- Lidarr requires Completed Download Handling to import files that your download client fetched. Enable it. (Completed Download Handling is on by default for new users.)
-
This error is typically associated with bad docker paths within either your download client or Lidarr
-
An example of bad (inconsistent) paths would be:
- Download client:
/mnt/user/downloads:/downloads
- Lidarr:
/mnt/user/downloads:/data
-
In this example the download client places its downloads into /downloads and tells Lidarr when its complete that the finished music is in /downloads. Lidarr then comes along and says "Okay, cool, let me check in /downloads." Well, inside Lidarr you didn't allocate a /downloads path you allocated a /data path so it throws this error.
-
The easiest fix for this is CONSISTENCY - if you use one scheme in your download client, use it across the board.
-
The Lidarr team recommends using /data as the base path.
- Download client:
/mnt/user/data/downloads:/data/downloads
- Lidarr:
/mnt/user/data:/data
-
Within the download client, specify where in /data to place downloads. This varies by client, but you should be able to tell it "Yeah, download client, place my files into /data/downloads/movies" and since you used /data in Lidarr when the download client tells Lidarr it's done Lidarr will come along and say "Sweet, I have a /data and I also can see /data/downloads/movies, all is right in the world."
-
For more detail, see the Docker Guide and TRaSH's Hard links and Instant Moves (Atomic-Moves) guide.
-
If you're crossing operating systems or native and docker then you need a remote path map. See TRaSH's Remote Path Guide for Radarr and Sonarr for more information.
- Within the application, the configured media library folder is the root folder. This isn't the root folder of a mount. Your download client has an incomplete or complete (or is moving completed downloads) into your root (library) folder.
- This frequently causes issues - including data loss - and you shouldn't do it. To fix this, change your download client so it isn't placing downloads within your root folder. Note that 'placing' also includes if your download client category points to your root folder or if NZBGet/SABnzbd have sort enabled and are sorting to your root folder.
- Please note that this check looks at all defined/configured root folders added not only root folders currently in use. In other words, the folder your download client downloads into or moves completed downloads to, shouldn't be the same folder you have configured as your root/library/final media destination folder in Lidarr.
- Find configured root folders (aka library folders) in Settings => Media Management => Root Folders
- One example is if your downloads are going into
\data\downloads then you have a root folder set as \data\downloads.
- It's suggested to use paths like
\data\media\ for your root folder/library and \data\downloads\ for your downloads.
- Review our Docker Guide and TRaSH's Hard links and Instant Moves (Atomic-Moves) Guide for more information on the correct and optimal path setup. Note that the concepts apply for docker and non-docker
Your download folder where your download client places the downloads and your root/library folder MUST be separate. Lidarr will import files from your download client's folder into your library. The download client shouldn't move anything or download anything to your library.
- The location your download client is downloading files to is causing problems. Check the logs for further information. This may be permissions or attempting to go from windows to linux or linux to windows without a remote path map.
- The location your download client is downloading files to is causing problems. Check the logs for further information. This may be permissions or attempting to go from windows to linux or linux to windows without a remote path map. See TRaSH's Remote Path Guide for more information.
- Lidarr (or the user lidarr is running as) can't access the location your download client is downloading files to. This is typically a permission issue.
- A file accessible via a remote path map appears to have disappeared before processing completed.
¶ Remote Path is Used and Import Failed
¶ Completed/Failed Download Handling
¶ Completed Download Handling is disabled
- Lidarr requires
Completed Download Handling to import files that your download client fetched. Enable it. (It's on by default for new users.)
- Your download client must retain its history of completed downloads until Lidarr imports them. If you disable history retention, Lidarr may not see the completed download before the client removes it. Configure your download client to keep (usenet) and pause, not remove, torrents after completion: either indefinitely or for at least 14 days.
- Sabnzbd: Switches => Post Processing => Keep Jobs must be 14 days or greater OR Keep All History
- Lidarr can manage removing completed downloads from your client via the download client settings in Lidarr. This lets Lidarr clean up your download client history.
- None of your indexers are set to allow automatic searches.
- Go into
Settings => Indexers, select an indexer you'd like to allow Automatic Searches and then click save.
- Lidarr uses the RSS feed to pick up new releases as they come along.
- To correct this issue, go to
Settings => Indexers, select an indexer, and enable RSS Sync.
- Lidarr requires indexers to discover new releases. See Settings => Indexers for instructions on adding them.
- None of the indexers you have enabled support searching. This means Lidarr will only be able to find new releases via the RSS feeds. But searching for releases (either Automatic Search or Manual Search) will never return any results. Obviously, the only way to remedy it's to add another indexer.
- None of the indexers you have enabled support interactive searching. This means the application will only be able to find new releases via the RSS feeds or an automatic search.
- Errors occurred while Lidarr tried to use one of your indexers. To limit retries, Lidarr won't use the indexer for an increasing amount of time (up to 24h).
- Lidarr triggers this mechanism when it can't get a response from the indexer (DNS, proxy/VPN, authentication, or an indexer issue) or can't fetch the nzb/torrent file.
- Please inspect the logs to determine what kind of error causes the problem.
- You can prevent the warning by disabling the affected indexer.
- Run the Test on the indexer to force Lidarr to recheck the indexer, please note that the Health Check warning won't always disappear immediately.
- The Jackett
/all endpoint is convenient, but that's its only benefit. Everything else is potential problems, so add each tracker individually.
- Even Jackett's devs say it should be avoided and shouldn't be used.
- Using the
/all endpoint has no advantages, only disadvantages:
- you lose control over indexer specific settings (categories, search modes, etc.)
- mixing search modes (IMDB, query, etc.) might cause low-quality results
- you can't use indexer-specific categories (>= 100000).
- slow indexers will slow down the overall result
- total results cap at 1000
- if one of the trackers returns an error, Lidarr will disable it and you won't get any results.
- Add each tracker in Jackett manually as an indexer in Lidarr
- Check out Prowlarr which can sync indexers to Lidarr and is from the Servarr development team.
- Check out NZBHydra2 which can sync indexers to Lidarr. Don't use their single aggregate endpoint; use
multi if you plan to use sync.
-
This error is typically identified if an artist is looking for a root folder but that root folder is no longer available.
-
This error may also be if a list is still pointed at a root folder but that root folder is no longer available.
-
If you would like to remove this warning simply find the artist that's still using the old root folder and edit it to the correct root folder.
-
Easiest way to find the problem artist is to:
- Go to the Artist (Library) Tab
- Create a custom filter with the old root folder path
- Select mass edit on the top bar and from the Root Paths drop down select the new root path that you want to move these artists to.
- Next you will receive a pop-up that states Would you like to move the Artist folders to 'root path' ? This will also state This will also rename the Artist folder per the Artist folder format in settings. Simply select No if you don't want Lidarr to move your files
- Run the Check Health Task in System => Tasks
-
Typically this simply means that Lidarr is no longer able to communicate via API or via logging in to your chosen list provider. Your best bet if the problem persists is to contact them in order to rule them out, as their systems maybe overloaded from time to time.
-
Review System => Events filtered for Warning (Warning & Errors) to see the historical failures or check logs for details.
-
Review System => Events filtered for Warning (Warning & Errors) to see the historical failures or check logs for details.
- This section will show you available disk space
- In Docker this can be tricky as it will typically show you the available space within your Docker image
- This will tell you about your current install of Lidarr
All these tasks can be run manually outside their scheduled times by hitting the icon to the far right of each of the tasks.
- The queue will show you upcoming tasks as well as a history of recently run tasks and how long those tasks took.
If you're looking for how to back up or restore your Lidarr instance, see the Lidarr backup FAQ.
The Backup section shows your previous backups (unless you have a fresh install with no backups yet).
Two options are available at the top of the screen:
- Backup Now - Triggers a manual backup of your Lidarr database.
- Restore Backup - Opens a screen to restore from a previous backup. Select Choose File to open a file dialog and choose a Lidarr zip backup.
If you have previous backups and want to download them, select a backup file to download it. To the right of each backup you have two options:
- Restore - Opens a confirmation window to restore from this backup.
- Delete - Deletes this backup.
The update screen shows the five most recent updates and the version you're running.
It also displays the developer release notes for each version.
A Maintenance Release contains bug fixes and other various improvements. Take a look at the commit history for specifics.
The events tab shows what has been happening within your Lidarr. Use it to diagnose minor issues. However, this doesn't replace Trace Logs discussed in Logging. Events are the equivalent of INFO Logs.
- Components - This column tells you which Lidarr component triggered the event
- Message - This column shows the message the component sent.
- Gear Icon - This option lets you change how many Components/Messages appear per page (Default is 50)
- Options at the top of the page
- Refresh - This option will refresh the current page, pulling a new events log
- Clear - This will clear the current events log allowing you to start from fresh
This page will allow you to download and see what current log files are available for Lidarr
On the top row there are several options to allow you to control your log files.
- The top row on the far left there's a dropdown that will allow you to switch from Log files and Updater Log Files
- Log Files - The bread and butter of any support issue; find more on log files here.
- Updater Log Files - This will show the log files associated with Lidarr's updater script
If you're on docker this will be empty as you should be updating by downloading a new docker image
- Refresh - This will refresh the current page and display any newly created logs
- Delete - This will clear all logs allowing you to start from fresh
- File Name - This will display the file name associated with the log
- Last Written - The local time Lidarr last wrote to this log file.
- Lidarr uses rolling log files limited to 1MB each. The current log file is always lidarr.txt, for the other files lidarr.0.txt is the next newest (higher numbers are older) up to 51 log files total. This log file contains
fatal, error, warn, and info entries.
- With Debug log level enabled, additional lidarr.debug.txt rolling log files will be present, up to 51 files. This log file contains
fatal, error, warn, info, and debug entries. It usually covers a ~40h period.
- With Trace log level enabled, additional lidarr.trace.txt rolling log files will be present, up to 51 files. This log file contains
fatal, error, warn, info, debug, and trace entries. Due to trace verbosity it only covers a couple of hours at most.