Files become "stuck" in download client when a better download is queued while original file is downloading

[asherbig]

Is there an existing issue for this?

• I have searched the existing open and closed issues

Is your feature request related to a problem? Please describe

Sometimes, an initial download (A) is grabbed. While A is downloading but before A has been imported, a second, better download (B), is grabbed. What ends up happening is B gets imported, and A is stuck in a state where it's downloaded, but unable to import, and unable to be deleted. Not a Custom Format upgrade for existing episode file(s)

Describe the solution you'd like

I imagine that Sonarr already has auto-deletion logic that looks something like:

if download.paused and download.imported:
  download.delete()

I am suggesting that logic be added to like so:

if download.paused and download.imported:
  download.delete()
elif download.paused and download.queued_before_current_imported_file: # new logic
  download.delete()

I think this would solve the problem that I'm having, since download A was queued before download B. It makes sense that download B was queued, since Sonarr thinks it's an upgrade over download A. But that also means that download A should now be in a "ready to be deleted" state, since download B is now the "primary download".

I still believe that paused logic should be respected. Downloads should not be deleted if they are not paused in the download client. This should help prevent deleting downloads before seeding requirements are met.

I also don't believe that this logic will lead to download loops, though I am likely not aware of all the possible edge cases that this code will run through that might lead to unwanted behavior.

Describe alternatives you've considered

Adding a delay to the download grabs.

Cons:

• missing "swarm" downloads
• adding X amount of time to the new content cycle
• Still not guaranteed to fix the problem, only aims to reduce the probability of it happening

Pros:

• It is currently possible to do

Anything else?

No response

[markus101]

Similar to #5515, but #4324 is likely the closest duplicate, as mentioned there hit and runs make this a complicated endeavor, no short term plans to implement queue management at this level, but as mentioned in #5515 you could do it with a custom script, either on grab or import.

[asherbig]

What are hit and runs?

Edit: I looked up the definition. I believe that the requirement for the torrent to be paused will prevent that issue? Assuming people have the "delete an imported download after pausing" box checked, then it's fair to assume that they've set up their pausing logic correctly. Or is there something else I'm missing?

[markus101]

Yes, only deleting when paused would overcome the H&R aspect of it.

Just being paused and grabbed before another download could still remove something that the user didn't want it to though, so there needs to be more safeguards than that, especially when we're talking about data that hasn't been imported.

[asherbig]

Ah, thanks for the response! What's a scenario where something might be removed that the user didn't want removed?

If the first download had just completed and imported before the second download started, then the end state after download 2 finishes and imports would be the same as the change I'm proposing. Oh maybe a little different: if the user has a trash directory, we would want to make sure the deleted download goes into the trash directory as if it had been imported I suppose.

[markus101]

I'm not sure offhand, but there are many reasons why something could be rejected that aren't "not an upgrade".

https://github.com/Sonarr/Sonarr/tree/develop/src/NzbDrone.Core/MediaFiles/EpisodeImport/Specifications

You could also potentially have the reverse problem, a file is grabbed because it's seen as an upgrade (usually because the indexer says it's X), but at import time it get stuck because it's actually Y.

Moving to trash could work, but in a seedbox scenario that could take a considerable amount of time and block other imports.

There are a lot of edge cases that could arise and lead to issues.

[markus101]

Perhaps an option for "removing" for torrents is having a removal category (like post import), that way it's not stuck in Sonarr's queue, but Sonarr doesn't force the deletion either.

For Usenet moving to a different folder and removing from history could be viable.

[asherbig]

You could also potentially have the reverse problem, a file is grabbed because it's seen as an upgrade (usually because the indexer says it's X), but at import time it get stuck because it's actually Y.

I agree, this is a real issue and is annoying. And it's similar to the scenario in the post, but I think it's different enough to not need to be addressed by the solution to this specific problem where queueing time leads to stuck downloads

[asherbig]

but Sonarr doesn't force the deletion either

What do you mean? Like Sonarr will not auto-delete ever? Or Sonarr will not auto-delete until certain conditions are met (paused, etc)?

[markus101]

Two things:

1. Some people perma seed everything, so they'd never want things deleted, but a different category would work for them
2. It's a lot safer to test things without removing them, so to start just changing the category would be a good start it's stop Sonarr from seeing them in queue and also prevent it from deleting something while all the kinks are worked out