Add feedback in the 'activity' tab about automatically performed searches/actions

[danudey]

Is your feature request related to a problem?

When a user performs any action which triggers an automatic search, either by manually tapping 'Automatic' on a season or episode or by triggering 'Search Monitored' for a series, there is no feedback whatsoever about what is queued, what is happening, or what the result was.

This can be confusing especially to new users, since they don't know if the action is ongoing, if it failed, or why it failed if so.

Describe the solution you'd like

The app already has an 'Activity' tab with a list of tasks. I propose separating this page into two categories:

1. Search tasks
2. Download tasks

At the barest level simply showing a list of searches and providing the same feedback that the user gets from a manual search would provide a lot more insight into the current process; I think this would be more than sufficient for an initial MVP or proof of concept.

Perhaps down the road, the task details could be expanded. Currently, tapping on a download task brings up the most relevant information - download progress, indexer used, language, etc. Tapping on a search task could bring up information on that search action, with fields something like:

Status: [Pending, In Progress, Failed, Download Queued, No Suitable Downloads Found]
Indexer(s): <list of indexers being searched>
Sub-tasks:
  FooBarSite: No results found
  DooDaaIndex: No results found matching the current quality filters
  ArugulaCom: Search failed (indexer unavailable?)
  KronkHub: Download found and added to queue

I'm going to open another suggestion to have failed 'season searches' fall back to 'individual episode search for each episode', and that's something that could also be displayed here - "no season results found, falling back to episode search".

Describe alternatives you've considered

At this point, the workaround flow that I use is:

1. Do an automatic search
2. Wait for 10-30 seconds
3. If nothing seems to happen, do a manual search so I can see what the issue is

This works, but is still cumbersome and not intuitive. Surfacing that information proactively would lead to a more pleasant user experience.

Additional context

No response

[tillkruss]

@danudey When you perform an automatic search in Radarr/Sonarr itself, what kind of feedback do you get?

Maybe related to #323.

[tillkruss]

Closing due to no response.

[joptimus]

@tillkruss Hey, I’d like to take a crack at this.

I agree with OP that the Activity tab is the right place for this, and I think it can be implemented without much churn to the existing patterns.

Proposed Direction

Split the Activity tab into two sections (using a picker at the top, matching the existing HistoryView / queue split):

1. Downloads
   The existing Queue list, unchanged.

2. Tasks
   A new list backed by Sonarr/Radarr’s /api/v3/command endpoint. This would show recent commands with live status:

   • queued / started / completed / failed
   • instance response message
   • result string (e.g. “Found 0 reports”, “Grabbed 1 release”)

Implementation Sketch

• Return the decoded command object from API.command (currently discarded as Empty)

• Add:

  • fetchCommand(id:)
  • fetchCommands()
    following the same pattern as fetchQueueTasks

• Introduce a new Commands observable store (parallel to Queue)

  • Poll every 5s for active commands (mirroring Queue.fetchTasks)

• Update all dispatchSearch call sites (Movie / Series / Episode context menus, MovieView)

  • Pass the returned command into Commands.track(...) so it appears immediately
  • Keep the existing “queued” toast behavior

• Add UI components:

  • CommandListItem
  • CommandSheet
    (mirroring QueueListItem / QueueItemSheet for consistency)

• Extend existing .xcstrings catalogs with new strings

Scope

Keeping this intentionally aligned with existing conventions:

• In-memory history (repopulated from GET /api/v3/command on tab appear, since instances maintain their own history)
• Filtered to search-related commands by default

Ill work on a PR for you to review

[tillkruss]

Sweet, post a video or screenshots when you have the UI ready.

[danudey]

@joptimus that sounds like it would be perfect!

@tillkruss sorry for not replying, this one got filtered into my junk mail for some reason.

[joptimus]

@tillkruss I submitted the PR with video and screenshots. @danudey I think this matches what you were talking about right?

[joptimus]

@danudey sorry man I tried, he is not interested in this feature.

[danudey]

@danudey sorry man I tried, he is not interested in this feature.

Thank you for putting in the time and effort, I really appreciate it!

[tillkruss]

@joptimus I'm not interested in features where I don't understand the need for them. I'm yet to get a clear answer for:

• What do Radarr/Sonarr currently do/offer that Ruddarr doesn't?
• Do Radarr/Sonarr solve the problem or are they also lacking what you want?

@danudey Can you show me how you're currently doing this in Sonarr, what your flow is with automatic searches? Successful ones and failures. Ideally a screen recording.

[tillkruss]

I think there are two low impact solutions for this, IF I understand problem correctly.

1. Open a PR to Sonarr that will add a new notification type for manually dispatched automatic searches.
2. Show a list of recently failed manually dispatched automatic searches in the Activity tab. The filtering for that has to be smart as in, limit the timeframe and skip false positives that did get fetched.

I guess it depends on which you prefer, refreshing lists and waiting for results or just relying on notifications (my preference).