downloads sit in queue at 99% (fixed... ?)

[undivided]

this issue popped up after my update manager (linux mint) pushed me the new 1.0 sabnzbd.
all my settings and configuration were maintained however any new nzb files detected would download fine up to the last 1% then hang as if it were waiting for some post processing. at first I thought it was because I didn't have the python yenc package setup but everything's been working fine for months so I installed yenc anyway got sabnzbd to recognize it, still downloads would hang on 99%.
I was just moving the folders out of incomplete then removing them manually from the queue because there was nothing wrong with the download, all files were there including the par2 sets which all verified out as good. a couple reboots and queue repairs didn't seem to resolve the issue either.
now I just did a fresh download this morning of a flac album and it actually processed through 100% like it used to, weird!
so I did another queue repair and then resumed the other 99% and they all started to complete and verified, weird!

not sure if anyone else has had this issue.

-linux mint 17.3 - 64bit / kernel 4.5 /

[sander]

How many different newsservers have you defined?

[Futureman83]

I have the same Problem, sabnzbd wont download the par2 files an every Downloads stuck at 99%.
To fix this problem i must klick "Status>>Repair"

SABnzbd Version: 1.0.1RC1
OS: Ubuntu 16.04
One Server

Edit: SABnzbd Version: 1.0.0 worked fine.
Edit2: An it moves the par2 fils in the unpack folder, with the unpacked file.

[safihre]

undivided: are you also on 1.0.1RC1? Or 1.0.0Final?

[Reddwaldd]

Good evening,

I am having the exact same issues as undivided and Futureman83.

Downloads will reach 99%ish and they will never get post-processed/completed. The majority of PAR2 files remains in the queue. If i check any incompleted items in the queue, when opening the queue content, most of it will be *Finished* with the exception of the .par2 files that will still have an *Active* status.
The repair button won't fix it.

OS version : Ubuntu Linux 15.10 (x64)
Kernel version : Linux 4.2.0-35-generic
SABnzbd version : 1.0.1RC1 [4eb486d]
Python version : 2.7.10 (default, Oct 14 2015, 16:09:02) [GCC 5.2.1 20151010]

It has been working A-1 for months before the upgrade to 1.0.1RC1 :/

Regards,

-Rw

[shypike]

Frustrating, but to this day we've never been able to reproduce this phenomenon.
Let alone fix it.
Is there any pattern?
Specific NZB-s?
Do you have multiple servers?

[Reddwaldd]

Hey there shypike,

I cannot seem to recognize any patterns. Something has definitely *broke* from 1.0.0 to 1.0.1RC1. It can be a mix of multiple variables but at this moment, I have no clue where to look.

Some answers to your questions

- The issue will occur with any NZBs. I tried with about 100 different ones, different sizes, different content and out of the blue, it will hang at 99%. My news servers have been the same ones for years, priority did not change as well (it changed from 0.7ish to 1.0ish with the new implemented changes to SAB). I assume that my news provider did not change anything on their end.
- I do have multiple servers configured with different priority pointing at different locations using different ports, but 90% of the time, it will always fetch from my topmost priority server

To add insult to injury, by rolling back to 1.0.0, everything start working back like a charm (like it always did ! :-)). The *Repair* function will fix the Download queue and the .par2 files will get downloaded in order for the repairing, verifying and post-processing tasks to complete. It is behaving exactly like Futureman83's setup.

I will let the queue heal itself and if you guys need logs or anything, just let me know, I could always upgrade to 1.0.1RC1, test a few NZBs and send you the logs or whatever files you need to debug.

Best regards,

-Rw

[shypike]

OK, so you see the problem being introduced when going from 1.0.0 to 1.0.1RC1.
That at least narrows it down.
Interesting, because we haven't really changed anything in the downloader for 1.0.1RC1

A debug log from a stalling job could be helpful.

[safihre]

What happens if, as soon as it stops, switch the priority to Force?

[nobrumski]

Upgraded to 1.01 and now seeing this. I have multiple servers.

[safihre]

Anyone with this problem, could you please do the following? We are not able to reproduce it so we need user input

Can you answer/do the following on 1.0.1:
- Everything is working fine now on 1.0.0 Final?
- How many servers do you have and what is the Timeout setting for each server? What have you set for Number of Retries (in Config->Switches)?
- No other active downloads, having them individually paused is also fine (otherwise the log is very hard to read)
- Now turn on Debug logging in the Status page
- Add NZB (small size is also fine, just one that stalls) and wait until it stall at 99%.
- What is now shown in the Connections page of the Status window?
- What is now shown in the individual download page of the job? Only par2 you mentioned before, can you edit those par2's or are they greyed out?
- What happens when you then switch the job priority to Force?
- What happens when you click Force Disconnect in the Status page?
- Can you then send us the log ([email protected] and [email protected]) No need to remove API keys or something, we don't care about those

[Timberwolf99]

Safifre,
just sent you some info and logs on this issue. in the mean time i'll roll back to 1.0.0 Final.

[johnsosius]

Hello,

After updating to 1.0.1 all my downloads are stuck on 100%.
Seems like the post-processing doesn't work anymore.
All files are downloaded including the par2 files and are in the incomplete folder.
Any thoughts?

[shypike]

Which OS are you using?
What happens if you set the priority of such a job to "Stop"?

[safihre]

We think it is a problem when QuickCheck is turned off and Download all par2 is turned on.

Enable QuickCheck, disable Download all par2 and do a Queue-repair to finish the stalled jobs.

Going to work on a real fix now!