Sonarr version (exact version): 22.214.171.12452
Mono version (if Sonarr is not running on Windows): 126.96.36.199
OS: QNAP 4.3.5
Description of issue: Some items remain in activity list after a successful download and import and the only way to delete them is to remove entry from downloader
I have a list of a number of random entries in the Activity list which show no files eligible for import, no time left and no status. On the download client, the download has finished and completed successfully. When you look at the history for the item in question, you see there is only the grab, BUT, the file has actually been imported, renamed and exists in the directory, and when you look at Files for the item it is there.
So basically Sonarr is importing the items correctly, but somehow not logging to itself that it did so, thus leaving the Activity item still active.
Most items process through correctly, but every now and then some items will not. It seems to be in batches, such as all the ones in a particular time period.
Yes, I understand that I can click on the X to remove it, but this also removes the history from the download client, which I do not want to do in the case of NZB items, and in the case of torrent items, I surely do not want to do until seeding is done. If there was a way to just remove the ‘Activity’ item without affecting the download client that would be awesome, but there isn’t.
Has anyone seen this problem?
It appeared to start after the 2018-06-23 update.
I do see a lot of 'import failed, path does not exist…" log entries for these items, but that’s because when Sonarr imported it, it deleted the completed-download directory as I have it configured to do. But every time it looks for completed downloads, it doesn’t find them and logs it for each item.
I am NOT posting the log files because the logs from all of the items are long gone, as I never know when this problem occurs until later and by that time the log is full of entries ‘import failed’ as it tries to import these items again over and over (but it already has and doesn’t know it). The logs presently only go back to the beginning of TODAY and not back to the day the issue occurred.