Is your feature request related to a problem? Please describe.
Not a bug exactly, more a friction point I ran into. With search_type = all and a moderately sized wanted list (~90 albums), I noticed that once a run starts grabbing matches, none of them get imported into Lidarr until monitor_downloads() has resolved every album in that run's grab_list — either completed, failed, or timed out via stalled_timeout. From reading through soularr.py, this seems to happen because the monitoring loop polls all albums together and doesn't move on to importing any of them until the whole grab_list is empty. So a handful of slow or stalled albums end up blocking import notifications for everything else in the batch, even albums that finished downloading within the first minute.
This made it genuinely hard for me to tell if anything was working, since Lidarr's Queue/Activity stayed empty for a long time despite slskd clearly having finished several downloads.
Describe the solution you'd like:
Something like triggering process_completed_album() for an album as soon as that specific album finishes, rather than waiting for the whole grab_list to drain. That way successful imports aren't gated behind the slowest item in the batch. I don't know the codebase well enough to know how feasible this is given the current loop/shared state design, so this is just a suggestion rather than something prescriptive.
Describe alternatives you've considered:
Lowering number_of_albums_to_grab helps in practice, since smaller batches resolve faster and reach the import step sooner. But it trades off how much of the wanted list gets attempted per run, so it's more of a workaround than a fix.
Additional context:
Happy to take a crack at this myself if it seems like a reasonable direction and you're open to a PR — just wanted to check in first since I'm not deeply familiar with the codebase's design intentions around this. Thanks for the tool, it's been great to set up and use overall.
Is your feature request related to a problem? Please describe.
Not a bug exactly, more a friction point I ran into. With
search_type = alland a moderately sized wanted list (~90 albums), I noticed that once a run starts grabbing matches, none of them get imported into Lidarr untilmonitor_downloads()has resolved every album in that run'sgrab_list— either completed, failed, or timed out viastalled_timeout. From reading through soularr.py, this seems to happen because the monitoring loop polls all albums together and doesn't move on to importing any of them until the whole grab_list is empty. So a handful of slow or stalled albums end up blocking import notifications for everything else in the batch, even albums that finished downloading within the first minute.This made it genuinely hard for me to tell if anything was working, since Lidarr's Queue/Activity stayed empty for a long time despite slskd clearly having finished several downloads.
Describe the solution you'd like:
Something like triggering
process_completed_album()for an album as soon as that specific album finishes, rather than waiting for the whole grab_list to drain. That way successful imports aren't gated behind the slowest item in the batch. I don't know the codebase well enough to know how feasible this is given the current loop/shared state design, so this is just a suggestion rather than something prescriptive.Describe alternatives you've considered:
Lowering
number_of_albums_to_grabhelps in practice, since smaller batches resolve faster and reach the import step sooner. But it trades off how much of the wanted list gets attempted per run, so it's more of a workaround than a fix.Additional context:
Happy to take a crack at this myself if it seems like a reasonable direction and you're open to a PR — just wanted to check in first since I'm not deeply familiar with the codebase's design intentions around this. Thanks for the tool, it's been great to set up and use overall.