I am running newest release of 3 (updated tonight actually) and i have not yet got logs but figure i would start a topic as maybe you are aware already.
I am doing some testing of my notification system (on grab, download, etc) so i picked a series i dont care about (Lucifer) and went to season 4 and did a manual search. Added 4 episodes so i could test the notifications. After the test i made some changes to my code and wanted to retest. Went to the folder and removed all the files and clicked re-scan so they would remove from Sonarr UI. Removed the torrent with data from Deluge. Picked the episodes again and they where sent to deluge (grab worked) but never imported (nothing happened after they downloaded).
Is there a cache somewhere that Sonarr refers to and it sees it has imported them already so it isn’t going to do so again? If so it may need cleared when the re-scan is performed and the episodes removed. I was able to reproduce this numerous times. Went to a different season and grabbed 4 episodes and they all worked fine. Issue was only related to doing the same season/episodes multiple times.
while a torrent can be grabbed multiple times, it will only be imported the first time through. its something to do with being able to handle seeding torrents. really wish it had an configurable expiry or a way to clear it though.
it is incredibly irritating though that sonarr doesnt warn you about this, and that it deletes the job/file withought any real indication of why. if you arent going to import the file because youve already done it before then at least leave the job/file there so i can sort it out myself. wastes so much bandwidth
ran into the issue when i deleted some stuff and thought it would be simpler to re-download than go through the hassle of a restore. eventually i went into the download client and changed the category so it wasnt sonarr and manually imported them instead
Noticed this morning that upgrades also don’t trigger the on import event either… Hmm
Maybe “On Import” shouldn’t say when it is successfully imported if it isn’t going to work on upgrading (technically it is still successfully imported just like On Grab also works for upgrades) but should say that it is successfully imported for the first time & “On Upgrade” should be used for any other import checks.
I figured as much and is why i added the section about clearing that information when a rescan is performed and the file no longer exists. Guess i’ll wait for his explanation and maybe itll make more sense (from an internal perspective). Thanks for the reply!
Some changes landed recently to improve this behaviour, but there is still more to do for it. Removing the series will clear the history and treat it like it’s never seen it before.
Ok. Re-Scan really should do this instead of removing the entire series (just imo) but at least there is a work around for now. Thanks for the link to the issue and the answer bud!
Your testing is making exposing this more than the typical use case and I don’t think detecting that a file is missing should cause a separate action to be forgotten, there are legitimate reasons why you’d remove a file, but not the torrent and not want it to suddenly show up again.
You might also be able to fake this by leaving the torrent in the client and telling Sonarr to grab it again. As long as your client “accepts” the torrent and doesn’t error Sonarr will add a new grabbed event which should bypass the already imported logic; it might require a restart of Sonarr as well though, since the queue is cached in memory and avoids reprocessing the same downloads.
A configurable expiry would mean after that expiry anything previously imported would show up as waiting to import and fail because it’s the same file or has been replaced. I don’t think you need to clear anything, it should just happen when the release is grabbed.
This is because it’s imported (albeit previously) and the seeding goals have already been met. This is a case where it’s obviously broken, but there isn’t a simple way to account for all the cases properly.
Ok so i turned on the On Upgrade and i guess the logic still doesn’t add up. Grab sends a unique “sonarr_eventtype” as does import. Upgrade does not… It simply piggybacks on the download and utilizes a couple extra fields (deleted information about previous file).
Why isn’t there an “Upgrade” eventtype if the reason is truly to differentiate? Is there documentation for how all this works, maybe that will help clear things up on what all is differentiated.
You’re thinking about it in the context of a custom script, but it existed before custom scripts ever did. It’s purpose was to allow for notifications when a file is first available, but not notify the user when that file was upgraded to another quality.
The fact that it sends the same event type is intentional to allow people that don’t care at the custom script level a single event type for all imports.