Swaparr removing queued usenet downloads

[BjoernUsw]

Problem:

Queued usenet downloads in SABnzbd will accumulate strikes erroneously even before the downloader starts downloading them.

Probable reason for the problem:

Sonarr and SABnzbd compound download times of usenet downloads as they will be processed sequentially and not in parallel like torrent downloads, so if you queue 10 items which each take 12 minutes to download, the last item will have a displayed estimated download time of 2h as that's the time it will be finished if the queue doesn't change.

Steps to reproduce:

1. Queue a big item in SABnzbd, it doesn't need to be related or even visible to any of the *arr tools, it just needs to have a download time longer than the max download time set in Swaparr
2. Queue any item in SABnzbd through any of the *arr apps connected with Huntarr and with Swaparr enabled in Huntarr
3. Watch this second item accumulate strikes in the Swaparr logs

Possible Solutions:

1. Implement a toggle switch to ignore stalled usenet downloads in Swaparr
2. Implement detection of usenet downloads which are queued but aren't actively downloaded at the moment. A quick solution would be to ignore usenet downloads with 0% progress, but this problem can also affect already progressed downloads if the queue gets reordered, for example by adding multiple other downloads with a higher priority.

PS:
This problem might also affect torrent downloads as qBit for example allows to set a maximum amount of parallel downloaded torrents, any new torrent added after this limit has been reached will be put in a queue to wait their term for one of the free active slots. I don't know how those queued items will be displayed in the *arr apps as it's been a while since I had more than a handful of actively downloading torrents at the same time.

This problem might also affect people who suffer from a general slowdown of downloads due to too many simultaneously active downloads, for example ill-timed updates on unrelated devices on the same network, spreading their bandwidth too thin, but I don't know if Swaparr could even detect this.