Recently added Drunkenslug as an indexer and Sonarr grabs NZB’s from there no problem and my download client downloads and unrars them with no dramas but then Sonnar fails the download and yet it is sitting there in my Unrar folder.
Doesn’t happen if the episode is grabbed from another indexer.
The error Sonarr gives is
Message: Download Failed - Out of Server’s retention?
So not sure what the problem is?
Do you get the error from sonarr or from your Download client if you look in the logs ?
Because normally you get that error from your usenet provider when you trying to retrieve something that’s older then the retention of your USP.
Or it’s not complete because of several reasons and you’re not able to download it.
Anything in the logs of your download client ?
Could it be set your retention of your usenet settings in sonarr to low and not to the retention of your USP ?
I get the error from Sonarr after my download client has downloaded the episode with no problem and it’s just sitting there on my hard drive waiting for Sonarr to put it in it’s folder.
Anything in the logs of sonarr why it isn’t processing the file ?
Does it show up as active in sonarr ?
The only thing is what I already posted which is clearly wrong because it has been downloaded on to my hard drive but for some reason Sonarr thinks it hasn’t been. It only happens with Drunkenslug too. The same episode downloaded by getting the nzb from other indexer works fine with Sonarr.
youre right in that the retention error doesnt make any sense if the file was downloaded and unrar’d but it means the download client sent sonarr that error message which may explain why sonarr is not doing anything about that file if its been told that the job failed
do your sonarr logs show it searching for the episode again after it fails? maybe post them so they can be looked at here?
Yes it searches again after Sonarr fails it.
Cant see any error in the download client logs.
Which log files? Debug?
The only thing I see that is different in Drunkenslug files is that it downloads the par files first rather than later if they are needed for repairs.
the par files going first shouldnt matter, its your download client that determines when the job is finished and tells sonarr its final status
if sonarr is searching again afterwards then its been told the job has failed so unless theres a bug in the sonarr code its most likely an issue with the download client returning the wrong job finished code for some reason.
sonarr debug logs from a failed job might help the developers (and it cant hurt). your download client may also have debug level logging you can turn on as well to see if it really is sending a fail or not
I doubt this thread will get much traction with the devs, none of the requested information when creating a new thread is given.
I’m not sure what more info I can give as I have had to remove DS as an indexer seeing Sonarr says anything I get from there fails.
My download client is Newsbin Pro.
as previously mentioned, several times, debug logs from sonarr if you want some quality help (its hard to tell whats going on when you cant see anything)
theres also this thread - https://forums.newsbin.com/viewtopic.php?f=43&t=43294
so newsbin pro does have debug logs - youll need to work out how to enable that and get the logs from it as well
from the above thread check if you have any unrar filters set
also you may get better traction in the newsbin forums as its the one telling sonarr that the download has failed when it hasnt
When opening a new topic in the help & support category, you get this entire text:
Sonarr version (exact version):
Mono version (if Sonarr is not running on Windows):
OS:
Debug logs:
Description of issue:
Additional Information:
I’m having the same issue. I didn’t realize it was Drunkenslug until I came across this thread. I’m also using Newsbin Pro. My issue is that the files would show as failed in Sonarr (but not actually fail) and repeatedly download the same episode over and over. My completed download handling is enabled but these Drunkenslug downloads would never import and I’d have to do it manually. Eventually the redownloading would stop but I’m not sure what the trigger is for that. Earlier today I manually downloaded and imported a show into Sonarr. I made sure to click the “update series info and scan disk” so that the show was detected (and stop downloading) but over the course of a couple hours later it had downloaded 4 more copies of the same show, several of which met my minimum quality criteria. Why would Sonarr continually download a show that it knows I have, which I manually imported, and which meets my quality cutoff? It doesn’t make sense. Anyways, going back and looking through the activity, it does appear to always be Drunkenslug. Newsbin pro shows the files downloaded as both failed and successful at the same time so I’m guessing that has something to do with it. Because of this problem, I even tried turning off the “retry download” option under the failed download handling but it would still redownload the same episode over and over regardless. Why would it retry if that option was turned off? That doesn’t make sense either. It’s almost as if Sonarr and Newsbin pro don’t recognize the files from Drunkenslug being downloaded correctly (or even attempted) and even when imported manually into Sonarr, it still doesn’t recognize that the download has been accomplished. Anyways, now that I know it is Drunkenslug I’ve just disabled the RSS sync so it doesn’t download without my manual searching.
please please please provide debug logs from sonarr, otherwise all we can do is guess at whats happening
if you can get debug logs out of newsbin as well then those would help too as you said its showing as failed in there so why wouldnt sonarr process it as failed and try to download another file.
which means you should also write in the newsbin forums as well as it seems the issue is more likely with it
if you post the debug logs we can take a look at them, otherwise there isnt much point
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.