Allow Lidarr to rescan ImportFailed albums #605

New issue

Closed

opened 2026-02-20 12:04:23 -05:00 by deekerman · 0 comments

deekerman commented

2026-02-20 12:04:23 -05:00

Owner

Originally created by @seeyabye on GitHub (Aug 27, 2019).

In a Remote Server Download Client & Local Server Lidarr setting, CDH will immediately fail album imports if a remote mount (i.e sshfs) is not used. This is has been an existing feature for Lidarr before PR #592 .

Example of Expected Workflow

Download Client on Remote Server using rTorrent/ruTorrent
Local Server/PC with Lidarr setup

On Lidarr, add a new album and initiate search & download request.
Download should be initiated on remote server's rtorrent
Upon completion of download, Lidarr should report Import failed, path does not exist or is not accessible by Lidarr: because the album does not exist on local server (after remapping from CDH's remote mapping).
A transfer script is initiated to transfer from the remote server to local server.
Lidarr will scan for this path's existence when Check For Finished Download's Task is executed.

Current Outcome
Upon completion of download, Lidarr reports Import failed, path does not exist or is not accessible by Lidarr: because the album is unavailable. Under the hood, Lidarr marks the album's TrackedDownloadStage state to ImportFailed.

On the front end, there are only two ways to rectify this error:

Manually import items
Remove, and restart steps for downloading the album.

In other words, there is no way to set the state of activity item from ImportFailed to Downloading again.

Describe the solution you'd like
The simplest solution I can give is to allow Lidarr to check for path existence when Check For Finished Download's task is executing.

Please refer to PR #946

Alternatives
Some other ideas include some manual work (still less manual than importing manually).

Include a manual recheck button to identify if albums has been downloaded.

Additional context
This issue is under discussion with @ta264 on Discord. Here are the important issues that he has raised:

Lidarr's import parsing is much much heavier than sonarr due to the difficulty in knowing which release you have downloaded and the fingerprinting, so we can't afford to run it repeatedly on an album that did download but doesn't match properly
This implementation is a stop-gap to partially items.
There's an ongoing implementation for Transfer Providers in Sonarr and that should rectify this issue.
Use sshfs

My counter argument is as follows:

Lidarr obtains the list of downloading album from the client and checks them one by one. When Lidarr finds a download that has been marked as ImportFailed it simply skips over it. Arguably parsing is expensive, but this is not parsing but merely checking for path existence. If the path exists, Lidarr proceeds, otherwise it fails. This is not costly at all.
For partially transferred items, a temporary folder solution can be used. This has been the case for Sonarr/Radarr. Arguably, it's not the best solution, but it works well for this unique workflow.
That issue has been proposed 4 years ago, and I doubt there will be anyone who can come up with a good solution to unify all download clients as most download clients are ignorant of Sonarr/Lidarr's existence.
This is not feasible if the download client is at the other end of the globe (i.e Europe and local server is in Asia).

To justify the aforementioned workflow, I would like to emphasize that sometimes having Lidarr on a local server is necessary for several reasons:

When you have a local NAS server
If you are on a private tracker, sometimes access to trackers has to be done with a home connection only.
Download Clients on remote servers are faster and more cost effective.

Originally created by @seeyabye on GitHub (Aug 27, 2019). In a Remote Server Download Client & Local Server Lidarr setting, CDH will immediately fail album imports if a remote mount (i.e `sshfs`) is not used. This is has been an existing feature for Lidarr before PR #592 . **Example of Expected Workflow** - Download Client on Remote Server using rTorrent/ruTorrent - Local Server/PC with Lidarr setup 1. On Lidarr, add a new album and initiate search & download request. 2. Download should be initiated on remote server's rtorrent 3. Upon completion of download, Lidarr should report `Import failed, path does not exist or is not accessible by Lidarr:` because the album does not exist on local server (after remapping from CDH's `remote mapping`). 4. A transfer script is initiated to transfer from the remote server to local server. 5. Lidarr will scan for this path's existence when `Check For Finished Download`'s Task is executed. **Current Outcome** Upon completion of download, Lidarr reports `Import failed, path does not exist or is not accessible by Lidarr:` because the album is unavailable. Under the hood, Lidarr marks the album's `TrackedDownloadStage` state to `ImportFailed`. On the front end, there are only two ways to rectify this error: 1) Manually import items 2) Remove, and restart steps for downloading the album. In other words, there is no way to set the state of activity item from `ImportFailed` to `Downloading` again. **Describe the solution you'd like** The simplest solution I can give is to allow Lidarr to check for path existence when `Check For Finished Download`'s task is executing. Please refer to PR #946 **Alternatives** Some other ideas include some manual work (still less manual than importing manually). - Include a manual recheck button to identify if albums has been downloaded. --- **Additional context** This issue is under discussion with @ta264 on Discord. Here are the important issues that he has raised: 1. Lidarr's import parsing is much much heavier than sonarr due to the difficulty in knowing which release you have downloaded and the fingerprinting, so we can't afford to run it repeatedly on an album that did download but doesn't match properly 2. This implementation is a stop-gap to partially items. 3. There's an ongoing implementation for **Transfer Providers** in Sonarr and that should rectify this issue. 4. Use `sshfs` My counter argument is as follows: 1. Lidarr obtains the list of downloading album from the client and checks them one by one. When Lidarr finds a download that has been marked as `ImportFailed` it simply skips over it. Arguably parsing is expensive, but this is not parsing but merely checking for path existence. If the path exists, Lidarr proceeds, otherwise it fails. This is not costly at all. 2. For partially transferred items, a temporary folder solution can be used. This has been the case for Sonarr/Radarr. Arguably, it's not the best solution, but it works well for this unique workflow. 3. That issue has been proposed 4 years ago, and I doubt there will be anyone who can come up with a good solution to unify all download clients as most download clients are ignorant of Sonarr/Lidarr's existence. 4. This is not feasible if the download client is at the other end of the globe (i.e Europe and local server is in Asia). ---- To justify the aforementioned workflow, I would like to emphasize that sometimes having Lidarr on a local server is necessary for several reasons: 1. When you have a local NAS server 2. If you are on a private tracker, sometimes access to trackers has to be done with a home connection only. 3. Download Clients on remote servers are faster and more cost effective.