No eta, it’ll be part of a bigger change.
Please edit your posts instead of double posting.
I have changed my configuration slightly instead of grabbing nzbs every 10 minutes I have changed the RSS retrieval in sonar to 17. Worst case if I continue to see more failures and can’t seem to figure out why the retry isn’t working I’ll have to try the delay on the category.
Thanks for your help.
Hey Markus,
It looks like SABNZBD updated to version 0.7.20 with this in the release notes:
http://tweakers.net/downloads/33833/sabnzbd-0720.html
I wonder if this will resolve the issues I have been having.
http://forums.sabnzbd.org/viewtopic.php?f=2&t=18337&p=97500&hilit=nzbdrone#p97500
Just saw your post lol
Not really, just means we don’t have to hunt for the new ID. That thread covers our issue, if a file was partially downloaded, even 0.1% it wouldn’t try to get more on a retry. Makes our retry mechanism very unreliable, of course if 99% was grabbed and it failed and we deleted everything to retry its not a lot better, but at least it has a chance to succeed.
when you mean a file was partially downloaded do you mean the NZB itself?
It would be awesome if they could on retry deleted all the incomplete files and grab the nzb again.
I am just a little confused as to what the retry actually does in sonar and sab if it grabs the NZB before the files are completely uploaded on retry does it just continue to grab those same incomplete files?
In a few cases lately very small amount but sometimes the retry will work.
I mean partially downloaded a file in part of the RAR set, if any of the file was partially download (even one block) SAB doesn’t try to redownload any other blocks in the file (at least thats my understanding).
SAB would need to know the expected file size, which isn’t reported, so its pretty much impossible without making assumptions/guessing.
Retry in Sonarr tells SAB to retry the NZB (whatever SAB actually does with it depends on the status of files that are referenced in the nzb), in most cases it retries the post processing. In the successful cases so few files were available when it was grabbed initially that it was able to actually get more content from your provider and complete some files).
1 Like
Good to know hopefully something can be done on the sabnzbd side that can actually pull down the nzb again on retry and remove all the old folders.
The problem being we have to wait for them to fix it and people to be using it to fix it. We could force a delete and regrab the same nzb, but then we’re likely to end up running into a dupe check.
I am going to use the sonnar delay hopefully it’ll minimize the failed downloads.
Any update on getting the delay set in minutes instead of hours?
Delay is currently set in minutes as of https://github.com/Sonarr/Sonarr/commit/a5dd0cce299567a2a4b2056af5c8b6c7cdf9af6e
1 Like
Its already in develop (Delay profiles) as @delphi_actual pointed to.
We’re also planning changes to make this process much more seamless (retries and failed downloads).
1 Like
Perfect that was quick!
Just setup a 10 minute delay that should hopefully fix most of my failures will report back.
Awesome would be nice if the SAB team would be able to force a redownload of the nzb but in the meantime the delay in minutes should do the trick.
That issue is two problems, one it needs to be added and two people need to upgrade so we can use it, otherwise we still look like we’re broken.
I just had a show finish and attempt to download before the 10 minute delay that I setup.
I think I have it setup properly…
Protocol is set to only Usenet amd delay is set to 10 minutes
It’s 10 minutes from when its posted (in most cases), could be later than that by the time its indexer and Sonarr sees it.
I will push up the delay to an hour and see if that helps resolve the issue.
If I set the delay to 60 minutes and the show is posted at 10PM it will not make it’s way into the SAB queue until at least 11PM?
Yes, exactly. It would get added to pending during the first RSS sync after its been posted and indexed then held until the first RSS sync 60 minutes after posting time.
Having some issues setup up the delay it may seem.
Here are my settings:
RSS Sync Interval: 10 minutes
Protocol Delay: Only Usenet
Usenet Delay: 60 minutes
Just had a show finishing airing at 8:30 it was posted on the indexer at 8:30 and was snatched and sent to my SAB at 8:34.
That’s using the default delay profile? Or a tagged one?
A debug log would be helpful to figure out what is going on.