Gandalf/sofarr
Public Access
0
0
Fork 0
Code Issues 1 Pull Requests Actions 1 Packages Projects Releases 59 Wiki Activity

Orphaned Sonarr/Radarr queue items not visible in Sofarr Active Downloads #73

New Issue
Closed
opened 2026-05-28 19:55:31 +01:00 by Gandalf · 3 comments
Gandalf commented 2026-05-28 19:55:31 +01:00
Owner
Copy Link
Copy Source

Summary

There are a number of downloads that are active / completed / failed but still in the Sonarr (or Radarr) queue, which are not visible in the active downloads dashboard in Sofarr. This prevents users from seeing critical status alerts (such as stalled downloads, import warnings, and errors) and using the "Blocklist & Search" feature to re-search them.

Technical Analysis & Root Cause

The issue lies in how active downloads are constructed and matched in the backend:

  1. In server/routes/dashboard.js, active downloads are built via buildUserDownloads inside server/services/DownloadBuilder.js.
  2. In server/services/DownloadBuilder.js, the builder retrieves a cache snapshot of both download clients (sabnzbdQueue, sabnzbdHistory, qbittorrentTorrents) and *arr queues (sonarrQueue, radarrQueue).
  3. However, buildUserDownloads only aggregates download data by iterating over the active download client items:
    • Matches SABnzbd slots (sabnzbdQueue.data.queue.slots) using DownloadMatcher.matchSabSlots
    • Matches SABnzbd history (sabnzbdHistory.data.history.slots) using DownloadMatcher.matchSabHistory
    • Matches qBittorrent torrents (qbittorrentTorrents) using DownloadMatcher.matchTorrents
  4. If a download item exists in the sonarrQueue or radarrQueue cache payload, but is NOT present in any of the download clients' active or completed item list (e.g., because the item finished and was removed/paused from the torrent/NZB client, it failed and was cleaned up, or it is in a download client instance not directly configured in Sofarr), it will never be matched and is completely omitted from the final userDownloads list.

Impact

  • Invisible Stalled/Import-Pending Items: Any download that completed but is waiting for manual import or interaction, or had a low disk space warning, or failed but remains in the Sonarr/Radarr queue, is completely hidden from the Sofarr UI.
  • Inoperable Blocklist Capability: Users cannot utilize the "Blocklist & Search" action on these unimported or stalled items in Sofarr because the card simply does not appear on their dashboard.

Proposed Solution

To resolve this issue, the download builder should handle unmatched *arr queue items as standalone objects:

  1. In server/services/DownloadBuilder.js, track which Sonarr/Radarr queue record IDs (arrQueueId) were successfully matched during the download client passes.
  2. Perform a secondary pass over the remaining unmatched sonarrQueueRecords and radarrQueueRecords.
  3. For each unmatched record:
    • Verify if it matches the current user's tag filtering (showAll or matchedUserTag).
    • Construct a standardized download object directly from the *arr queue record. Since there's no corresponding item in the download client, mock/map relevant properties:
      • client: queueRecord.protocol (e.g., usenet, torrent) or 'sonarr'/'radarr'
      • status: Map from queueRecord.status or queueRecord.trackedDownloadState (e.g. 'Stalled', 'Import Pending', 'Downloading', 'Failed')
      • progress: Map from 100 - (queueRecord.sizeleft / queueRecord.size * 100) or standard *arr queue progress fields
      • importIssues: Extract via DownloadAssembler.getImportIssues(queueRecord)
      • Include full *arr metadata, tags, and arrQueueId for blocklist actions.
  4. Append these standalone unmatched downloads to the final userDownloads array returned to the dashboard SSE stream.
### Summary There are a number of downloads that are active / completed / failed but still in the Sonarr (or Radarr) queue, which are not visible in the active downloads dashboard in Sofarr. This prevents users from seeing critical status alerts (such as stalled downloads, import warnings, and errors) and using the "Blocklist & Search" feature to re-search them. ### Technical Analysis & Root Cause The issue lies in how active downloads are constructed and matched in the backend: 1. In `server/routes/dashboard.js`, active downloads are built via `buildUserDownloads` inside `server/services/DownloadBuilder.js`. 2. In [server/services/DownloadBuilder.js](file:///home/gordon/CascadeProjects/sofarr/server/services/DownloadBuilder.js), the builder retrieves a cache snapshot of both download clients (`sabnzbdQueue`, `sabnzbdHistory`, `qbittorrentTorrents`) and *arr queues (`sonarrQueue`, `radarrQueue`). 3. However, `buildUserDownloads` only aggregates download data by iterating over the active download client items: - Matches SABnzbd slots (`sabnzbdQueue.data.queue.slots`) using `DownloadMatcher.matchSabSlots` - Matches SABnzbd history (`sabnzbdHistory.data.history.slots`) using `DownloadMatcher.matchSabHistory` - Matches qBittorrent torrents (`qbittorrentTorrents`) using `DownloadMatcher.matchTorrents` 4. If a download item exists in the `sonarrQueue` or `radarrQueue` cache payload, but is **NOT** present in any of the download clients' active or completed item list (e.g., because the item finished and was removed/paused from the torrent/NZB client, it failed and was cleaned up, or it is in a download client instance not directly configured in Sofarr), it will **never** be matched and is completely omitted from the final `userDownloads` list. ### Impact - **Invisible Stalled/Import-Pending Items**: Any download that completed but is waiting for manual import or interaction, or had a low disk space warning, or failed but remains in the Sonarr/Radarr queue, is completely hidden from the Sofarr UI. - **Inoperable Blocklist Capability**: Users cannot utilize the "Blocklist & Search" action on these unimported or stalled items in Sofarr because the card simply does not appear on their dashboard. ### Proposed Solution To resolve this issue, the download builder should handle unmatched *arr queue items as standalone objects: 1. In `server/services/DownloadBuilder.js`, track which Sonarr/Radarr queue record IDs (`arrQueueId`) were successfully matched during the download client passes. 2. Perform a secondary pass over the remaining unmatched `sonarrQueueRecords` and `radarrQueueRecords`. 3. For each unmatched record: - Verify if it matches the current user's tag filtering (`showAll` or `matchedUserTag`). - Construct a standardized download object directly from the *arr queue record. Since there's no corresponding item in the download client, mock/map relevant properties: - `client`: `queueRecord.protocol` (e.g., `usenet`, `torrent`) or `'sonarr'`/`'radarr'` - `status`: Map from `queueRecord.status` or `queueRecord.trackedDownloadState` (e.g. `'Stalled'`, `'Import Pending'`, `'Downloading'`, `'Failed'`) - `progress`: Map from `100 - (queueRecord.sizeleft / queueRecord.size * 100)` or standard *arr queue progress fields - `importIssues`: Extract via `DownloadAssembler.getImportIssues(queueRecord)` - Include full *arr metadata, tags, and `arrQueueId` for blocklist actions. 4. Append these standalone unmatched downloads to the final `userDownloads` array returned to the dashboard SSE stream.
Gandalf added the Kind/Bug
Priority
High
2
Area/Matching labels 2026-05-28 19:55:31 +01:00
Gandalf commented 2026-05-29 12:46:27 +01:00
Author
Owner
Copy Link
Copy Source

Resolved in commit 50e1e09 on develop.

Resolved in commit 50e1e09 on develop.
Gandalf commented 2026-05-29 12:57:16 +01:00
Author
Owner
Copy Link
Copy Source

Added trace logger matching in titleMatches and a JSDoc example for buildArrDownload in commit 0364a3c.

Added trace logger matching in titleMatches and a JSDoc example for buildArrDownload in commit 0364a3c.
Gandalf commented 2026-05-29 13:28:47 +01:00
Author
Owner
Copy Link
Copy Source

Resolved in develop branch in commits:

  • 50e1e09 (support orphaned *arr queue items and improve download matching reliability)
  • 0364a3c (JSDoc examples and log helper tracing)
  • 2f32edf (regression fix to restrict arrInstanceKey to admin users)

Merged into main in release v1.7.35.

Resolved in develop branch in commits: - 50e1e09 (support orphaned *arr queue items and improve download matching reliability) - 0364a3c (JSDoc examples and log helper tracing) - 2f32edf (regression fix to restrict arrInstanceKey to admin users) Merged into main in release v1.7.35.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Docker
Docker image and container packaging
 Area/Download Clients
Download client integrations
 Area/Frontend
Client-side UI and build tooling
 Area/History
History and completed downloads views
 Area/Logging
Log streaming, file handling, and debug infrastructure
 Area/Matching
Matching and correlation logic
 Area/Proxy
Upstream service proxy routes
 Area/SSE
Server-Sent Events and real-time streaming
 Area/Webhooks
Webhook processing and reliability
 Compat/Breaking
Breaking change that won't be backward compatible
 Compat/Non-Breaking
Non-breaking compatibility change
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label Area/Matching Kind/Bug
Priority
High
2
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Gandalf
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Gandalf/sofarr#73
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?