So I’ve tried, I really have… I’ve spent several months reading posts from the forum with no help. I’m simply trying to get around simple propagation issues, for some reason the retries just don’t work. The one thing I really really want to avoid is starting *Drone from scratch so hoping I can get some help.
I’m on a windows platform, latest stable release of *drone and using the latest stable of nzbget (all on the same box)
Here are my CDH / FDH settings:
CDH - Enable
CDH Remove - No
FDH - Enable
Re-download - Yes
Remove - No
Grace - 6
Retry Int. - 10
Retry Count - 10
I do have an error during the retry process that I cant seem to nail down:
http://pastie.org/private/b8w6pjdxu7vw6jlnp6m7w
I believe this issue has already been fixed in develop and should make its way to master in the next week, barring any issues.
Currently adding a delay would be the best way to deal with these propagation issues, but with it being 1 hour increments its not ideal.
Markus, thanks for the reply. I’m a tad confused then, NZBget never has any retries, so if this is an expected behavior what is the point, is it to simply retry for another release? If I wait even 10 minutes on any of these failed releases (due to propagation) it works fine. And I very much agree that hours is not the way to go for a retry interval, it should be set at 60 minutes by default but any retry time should be allowed, really many releases could be pulled within an hour.
Its a bug, not expected. The retry tries the same release, not a different one, when the retry count is met then the release is blacklisted and another release is sought.
Propagation can hit in a couple different ways:
- The indexer creates the nzb with missing files, which will fail even on retry
- The indexer create the complete nzb, but your servers haven’t received all the files so a retry is likely to resolve it.
If #1 is the case then you will continue to have problems, but drone can’t easily determine (if at all) which is the actual issue.