qBittorrent download Import Blocked

[deLbe321]

Hi.

On fresh installation of Listenarr version 1.3.3 there is a problem with importing files downloaded through qBittorrent 5.2.3.

Steps to reproduce:

1. Import indexers through Prowlarr.
2. Add qBittorrent client
3. Add an item to library
4. Manual search for an item in indexers and click button to download
5. Observe how download becomes completed in Activity tab
6. Observe how completed item changes it's status to "Import Blocked"
7. Item stays in Activity tab as "Import Blocked" and in the library as "Missing"

In logs there is nothing that could tell what is wrong:

2026-08-23 13:36:33.801 +00:00 [DBG] [Listenarr.Application.Downloads.Queue.DownloadQueueService] Client qBittorrent: showing 2 queue items
2026-08-23 13:36:33.801 +00:00 [DBG] [Listenarr.Infrastructure.Downloads.Queue.QueueMonitorProcessor] Queue changed, broadcasting update (2 items) [polling: 15s]
2026-08-23 13:36:36.815 +00:00 [INF] [Listenarr.Infrastructure.Downloads.Monitoring.DownloadMonitorProcessor] DownloadMonitorService found 0 active downloads
2026-08-23 13:36:36.815 +00:00 [INF] [Listenarr.Infrastructure.Downloads.Monitoring.DownloadMonitorProcessor] No active downloads mapped to enabled download clients; skipping client polling
2026-08-23 13:36:48.806 +00:00 [INF] [Listenarr.Application.Downloads.Queue.DownloadQueueCandidateLoader] Loaded 1 queue display candidates, 1 queue matching candidates, and 1 known client IDs
2026-08-23 13:36:48.806 +00:00 [DBG] [Listenarr.Application.Downloads.Queue.DownloadQueueCandidateLoader] Final filtering result: 1 downloads to include in queue filtering (0 DDL, 1 external), 1 in matching pool
2026-08-23 13:36:48.808 +00:00 [DBG] [Listenarr.Infrastructure.DownloadClients.Qbittorrent.QbittorrentAdapter] Authenticated to qBittorrent for client <redacted some id>
2026-08-23 13:36:48.808 +00:00 [INF] [Listenarr.Infrastructure.DownloadClients.Qbittorrent.QbittorrentAdapter] Fetching qBittorrent queue filtered by category: audiobooki
2026-08-23 13:36:49.837 +00:00 [INF] [Listenarr.Application.Downloads.Queue.DownloadQueueService] Client qBittorrent has 18 queue items
2026-08-23 13:36:49.838 +00:00 [INF] [Listenarr.Application.Downloads.Queue.DownloadQueueService] Database has 1 Listenarr downloads for metadata enrichment

Paths in containers:
qBittorent has mounted in docker /nas:/nas
Downloads path: /nas/downloads/audiobooks

Listenarr has mounted in docker /nas:/nas
Has access to qBittorrent downloads path as it's /nas/downloads/audiobooks
Root path is /nas/media/audiobooks which is also accessible.

[m4bard]

I have not reproduced your case, so I cannot say what your import actually hit. But I went looking for why the log is empty, and I think that part is answerable from the code. Everything below is 1.3.3 (d25b3e1).

The reason is discarded before anything can log it

FileMover.CheckAsync runs before any destination work and decides whether the downloaded file can be published. It ends with a catch that folds seven exception types into one outcome (listenarr.infrastructure/FileSystem/FileMover.SourceCapability.cs:104-112):

catch (Exception exception) when (exception is
    IOException or UnauthorizedAccessException or Win32Exception
        or InvalidOperationException or NotSupportedException
        or PathTooLongException or System.Security.SecurityException)
{
    return FilePublicationSourceCapabilityResult.Unsupported(
        "The source file cannot be pinned to a durable physical generation and content proof.",
        FilePublicationSourceCapabilityFailureKind.Unavailable);
}

exception is bound and never used. A permissions problem and a file the client still has open both leave the same fixed string behind, and the exception itself is gone. The catch immediately above it (:100-103) does return exception.Message, and the sibling catch over almost the same exception family in FileMover.PathSafety.cs:82-92 logs the exception before returning, so this one looks like an oversight.

Downstream, DownloadImportService.ResolvePublishableSourceProofAsync logs that fixed string at Warning and returns null (listenarr.application/Downloads/Import/DownloadImportService.DirectoryOwnership.cs:208-225). The import loop turns the null into an ImportResult.ImportFailure, whose message is "Unable to perform {action} on {source} to {destination}" (listenarr.domain/Downloads/ImportResult.cs:91-103). The job then records "Unable to import at least one file for the job (see the log entries)" and the download record gets "See the log of job {id} for more information" (DownloadProcessingJobProcessor.cs:136-138). Both of those point at text that never contains a cause.

It only tries once

ProcessJobAsync has seven failure points that call ScheduleRetryAsync (lines 232, 248, 261, 271, 383, 405, 443): the source path missing, fetching from the client, the files on disk not matching the client's list, marking the item imported, enqueuing the scan, committing finalization. Those get four attempts in total, with exponential backoff (DownloadProcessingJob.ScheduleRetry, listenarr.domain/Downloads/DownloadProcessingJob.cs:230-253).

The file import itself is not one of them. Lines 304-309 call FailImportAsync, which marks the job Failed on the first failure with RetryCount still 0, and ProcessQueueAsync:125-139 then sets the download to ImportBlocked. That matches what f1fson described in #783: stuck in ImportBlocked with importAttempts: 0 and no automatic retry.

Getting back out is harder than it looks, too. POST /api/v1/downloads/{id}/retry-import sets the download to ImportPending (Download.Unblock(), listenarr.domain/Downloads/Download.cs:216-225), but as far as I can tell nothing ever enqueues a processing job for an ImportPending download. DownloadProcessingJobService.EnqueueAsync refuses any status other than Completed (:54-57); the only caller for external clients is the transition into Completed in DownloadMonitorService.TriggerCallbacks (:294-312), which returns early when the status did not change; and ImportPending is shielded from client telemetry in QueueItemConverter.cs:13-17, so it cannot reach Completed again. There is no UI for that endpoint either. git grep retry-import fe/ finds nothing. That leaves the download in the state t3chnaztea describes in #758.

Both halves look small from here. Making the import failure call ScheduleRetryAsync like its seven siblings is a one-line change, and it leaves the terminal behaviour alone: once the attempts are spent the job still fails and the download is still blocked, it just stops happening on the first try. Logging the discarded exception is a log statement. I have not sent either as a PR, because this is the area #864 rewrote and #878 is still moving, and I would rather not put a patch in front of that. I have both on a branch with a test if they are useful.

For comparison, Readarr keeps this level-triggered. ProcessMonitoredDownloadsCommand re-examines every trackable download sitting in ImportPending on each run rather than acting only on the edge into completion, and CompletedDownloadService.Import carries the per-file errors onto the tracked download with new TrackedDownloadStatusMessage(Path.GetFileName(...), v.Errors) instead of replacing them with a generic string. I read those on develop, so they may have moved since.

I still cannot tell you what your file hit. If the logging change lands, the exception type on its own would probably identify it.