Page 1 of 1

Download exits early breaking retries

Posted: July 5th, 2021, 2:45 am
by pancus
Dunno if anyone else reported this but I noticed this in 3.3.1, could be in earlier versions.

Lets say I'm downloading an nzb with 10 files, lets say the files are 50M each. Sab gets about halfway through then decides to stop. At this point one or two of the files will be way below what is on the server. Lets say the first three files hover around 47M and the next two only got about 5M in before sab stopped. Now when I click retry it will not retry any existing files. This makes it very unlikely that it will be able to repair.

I have fixed several downloads today by going into the folder of the failed download (too few repair blocks), deleting the tiny files, clicking retry, sab will then download a better version of that file and the repair is successful.

Also is there a way to to tune when sab will give up? Seems to give up way too early sometimes.

Re: Download exits early breaking retries

Posted: July 5th, 2021, 3:36 am
by sander
I don't fully understand what you describe, but anyway
sab will then download a better version of that file
SAB will do that? That looks like Radarr/Sonarr behaviour.
Also is there a way to to tune when sab will give up?
Maybe req_completion_rate (so: http://127.0.0.1:8080/config/special/#r ... etion_rate) ... set it to a much lower percentage like 20% ... ?

Re: Download exits early breaking retries

Posted: July 5th, 2021, 3:58 am
by pancus
If you delete the file then "retry" yes it will redownload the file. And req_completion_rate won't let me go below 100.

Re: Download exits early breaking retries

Posted: July 5th, 2021, 4:51 am
by sander
pancus wrote: July 5th, 2021, 3:58 am If you delete the file then "retry" yes it will redownload the file.
From the same server? Later on it is available?

If so, check out http://127.0.0.1:8080/config/switches/# ... tion_delay

Re: Download exits early breaking retries

Posted: July 5th, 2021, 5:08 am
by safihre
Sab decides to stop because the download can't be completed. You can disable that in Config Switches, Abort jobs that can't be completed.
But it sounds like you are able to complete them later on, so maybe you are downloading files that are too fresh? In that case you could try setting a Propagation Delay of for example 1 hour.

Re: Download exits early breaking retries

Posted: July 5th, 2021, 2:40 pm
by pancus
Now that I'm awake lets try this again.

Sab starts downloading a nzb.
Sab thinks it cannot complete so it stops.
The files that were currently being downloaded are saved as truncated.
If you click "retry" it will not redownload the truncated existing files.
There is almost no chance a repair will work now.

Now for a handful of downloads that stopped I tried this:
Go into the folder, delete the obviously truncated files (eg. 5M when the other files are ~50M)
"Retry" the download.
Some complete.

I think the issue here, at least for me, is sab giving up too early. But code-wise you might want to make note of files that were not fully attempted to be downloaded.

Re: Download exits early breaking retries

Posted: July 6th, 2021, 1:01 am
by safihre
I agree, this case indeed isn't handled well when there's a retry of partial data. Solving it is hard and would require quite a big refractor to keep track of every article of each file, which we don't do now.

But again my question: how are you able to repair the job later on? Because again, it sounds like initially the data isn't available but when you try again, it is there.
So this seems to me a Propagation Delay problem.

Re: Download exits early breaking retries

Posted: July 6th, 2021, 2:08 am
by pancus
I don't know. If the download fails with too few repair blocks rerunning it won't fix it. It's when sab stops early I can sometimes fix it.

Re: Download exits early breaking retries

Posted: August 6th, 2021, 9:01 am
by Puzzled
As an alternative to tracking all the articles it could have an option that makes it redownload incomplete files. It's not ideal but it would fix the issue in this case.