13 Health Checks
ta264 edited this page 4 years ago

This page contains a list of health checks errors. These health checks are periodically performed performed by Lidarr and on certain events. The resulting warnings and errors are listed here to give advice on how to resolve them.

System warnings

Mono version is less than 3.10, upgrade for improved stability

Lidarr is written in .Net and requires Mono to run. Versions of 3.10 and above resolved various stability issues we experienced in the past and is considered the minimum supported version.
Mono version 4.x and higher are also available and provides a better experience on certain platforms.

Update to .NET Core version

Newer versions of Lidarr are targeted for .NET Core. We provide legacy mono builds for those platforms that cannot use .NET Core. You are running one of these legacy builds but your platform supports .NET Core.

This should only happen on linux hosts. To remedy, download the correct build for your architecture: x64 or arm64 or arm.

Back-Up your existing configuration before the next step.

Delete your existing binaries and replace with the contents of the .tar.gz you just downloaded. DO NOT JUST EXTRACT THE DOWNLOAD OVER THE TOP OF YOUR EXISTING BINARIES, YOU MUST DELETE THE OLD ONES FIRST. Update your startup script to call Lidarr instead of mono --debug Lidarr.exe

If Lidarr doesn't start make sure you have the dependencies listed here installed.

fpcalc missing

Lidarr can use chromaprint audio fingerprinting to identify tracks. This depends on an external binary, which is distributed with Lidarr for Windows and macOS but must be provided independently on Linux.

To fix this on a native Linux instance, install the appropriate package using your package manager and make sure that fpcalc is on your PATH (this can be checked using which fpcalc and verifying that the correct location of fpcalc is returned):

Distribution Package
Debian/Ubuntu libchromaprint-tools
Fedora/CentOS chromaprint-tools
Arch chromaprint
OpenSUSE chromaprint-fpcalc
Synology chromaprint Troubleshooting

If you are using Docker then make sure your container is up-to-date. The recommended LinuxServer container has already been updated to include this new dependency.

If this occurs on Windows or macOS then make sure the file fpcalc.exe or fpcalc bundled with the installer is in the application directory.

New update is available

Rejoice, the developers have released a new update. This generally means awesome new features and squashed piles of bugs (right?). Apparently you don't have Auto-Updating enabled, so you'll have to figure out how to update on your platform. Pressing the Install button on the System -> Updates page is probably a good starting point. But while you're at it, read the change log to find out what the relevant changes were.

(This warning will not appear if your current version is less than 14 days old)

Cannot install update because startup folder is not writable by the user

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.

Updating will not be possible to prevent deleting AppData on Update

Lidarr detected that AppData folder for your Operating System is located inside the directory that contains the Lidarr binaries. Normally it would be C:\ProgramData for Windows and, ~/.config for linux.
Please look at System -> About 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 is running Lidarr and copy the current contents of the ~/.config/Lidarr directory to preserve your database.

Could not connect to signalR

SignalR drives the dynamic UI updates, so if your browser cannot connect to SignalR on your server you won't see any real time updates in the UI.

The most common occurrence of this is on versions > 0.7.1.1381 combined with an nginx reverse proxy. Nginx requires the following addition to the location block for Lidarr:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;

Make sure you do not include proxy_set_header Connection "Upgrade"; as suggested by the nginx documentation. THIS WILL NOT WORK

See https://github.com/aspnet/AspNetCore/issues/17081

Download Clients

No download client is available

A properly configured and enabled download client is required for Lidarr to be able 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.

Unable to communicate with download client

Lidarr was unable to communicate with the configured download client. Please verify if the download client is operational and double check the url. This could also indicate an authentication error.

Download clients are unavailable due to failure

One or more of your download clients is not responding to requests made by Lidarr. Therefore Lidarr has decided to temporarily stop querying the download client on it's 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 in all likeliness 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.

Permissions error

Lidarr needs access to your files to move/rename. Make sure the user running Lidarr has read/write permissions on your download and library directories. This can be an issue on Windows too - make sure files are not marked read-only by your download client.

Bad remote path mapping

If your download client is on a different host then you will most likely need to tell Lidarr how paths on the remote host translate to local paths.

Settings->Download Client->Remote Path Mapping is an option to configure Lidarr to translate the remote path to something locally accessible.

For example:
Suppose I configured a remote Sabznzbd instance with the Host 10.2.3.4 in Lidarr and that Sabnzbd instance uses /sda3/download/sabnzbd/completed as root folder for completed downloads. Suppose that that path is available as \\10.2.3.4\sabnzbd\completed on the machine running Lidarr.
Then you would add a Remote Path Mapping for:

  • Host=10.2.3.4
  • RemotePath=/sda3/download/sabnzbd
  • LocalPath=\\10.2.3.4\sabnzbd

Docker: Bad remote path mapping

A download client in a docker container is similar to the remote download client case above. As well as setting the remote path mapping correctly you will also need to make sure that the relevant directories are mounted in the container.

If you are unsure how to do this you should consider not using docker and running Lidarr natively.

See here for more details on setting up path mappings and permissions in docker.

Enable Completed Download Handling

Lidarr requires Completed Download Handling or a properly configured Drone Factory to be able to import files that were downloaded by the download client. It is recommended to enable Completed Download Handling.

(Completed Download Handling is enabled by default for new users.)

Completed/Failed Download Handling

Completed Download Handling is disabled

(This warning is only generated for existing users before when the Completed Download Handling feature was implemented. This feature is disabled by default to ensure the system continued to operate as expected for current configurations.)

It's recommended to switch to Completed Download Handling since it provides better compatibility for the unpacking and post-processing logic of various download clients. With it, Lidarr will only import a download once the download client reports it as ready.

If you don't wish to enable Completed Download Handling at all and wants to remove the warning. You can enable and then disable Completed Download Handling. This obviously isn't recommended.

If you wish to enable Completed Download Handling you should verify the following:

  • Warning: Completed Download Handling only works properly if the download client and Lidarr are on the same machine since it gets the path to be imported directly from the download client.
  • If you added a post-processing script to Sabnzbd/NzbGet to notify Lidarr that it should scan the Drone Factory. You SHOULD disable this script to prevent conflicts.
  • Completed Download Handling and the Drone Factory cannot be configured for the same directory. If Completed Download Handling detects a download resides in the Drone Factory it will be ignored. (again to prevent conflicts)
    You should reconfigure Lidarr to use a different Drone Factory Folder or disable it altogether.
    Alternatively you can change the output folder for the Category, as long as that output folder is not a subdirectory of the Drone Factory Folder.

Both Completed Download Handling and the Drone Factory logic generates Import Events in history while importing files. However, only Completed Download Handling associates this Import event with a Download Client history item. If Completed Download Handling was enabled recently, your download client may still contain history items that were already imported but do not have a history event with the same unique id. Lidarr attempts to resolve this issue automatically, occassionally Lidarr may be unable to make that association and cause a 'Completed' download to be listed in the History -> Queue table forever. The easiest way to resolve this is to clear your Download Client history, or only those individual items. Alternatively you can rename the category.

Indexers

No indexers are enabled

Lidarr requires indexers to be able to discover new releases. Please read the wiki on instructions how to add indexers.

Enabled indexers do not support searching

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 albums (either Automatic Search or Manual Search) will never return any results. Obviously, the only way to remedy it is to add another indexer.

Indexers are unavailable due to failures

Errors occurs while Lidarr tried to use one of your indexers. To limit retries, Lidarr will not use the indexer for an increasing amount of time (up to 24h).
This mechanism is triggered if Lidarr was unable to get a response from the indexer (could be dns, connection, authentication or indexer issue), or unable to fetch the nzb/torrent file from the indexer. 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 will not always disappear immediately.

Artist Folders

Missing root folder

This message may appear if a previous root folder is no longer used. To remove old root folders:

  1. Begin adding a new Artist by searching for a name, but do not submit
  2. In the 'Path' dropdown, select 'Add a different path'
  3. Click the cross at the end of a row to remove the unused path

Note - if the folder has been removed from the operating system, you will need to recreate the folder in the operating system, and restart Lidarr, or else you will not be able to select it from the dropdown box. After that you can remove the path from the operating system.

The message will continue to appear until all artists have their root folder updated to the new root folder. To change the root folder for other artists, visit the artist editor.