SABnzbd Forums

Safihre, I noticed two situations.

One: 100% disk usage cause by sabnzbd and prolly by sickbeard moving the finished file. This time the queue was still filling up and there seemed to be a lot of IO backlog present. In order to regain control over the disk killing the unrar process isn't enough. It will start up since sabnzbd docker is still running and revamping the process. I did manage to kill it by for killing it (docker rm -f [dockername]

Two: 300Gig of queue downloading and creating 8-9 "Unable to stop the unrar process." hourly. Though even having quite a lot of time having 100% load the queue ended and finished all tasks. I didn't see any dangling unrar processes after it finished downloading. In that situation one could argue it's working as expected. What isn't explained is why during the unrar process sabnzbd warns about "Unable to stop the unrar process." during this 'normal' routine. See prometheus graphs: https://imgur.com/a/SXcPvAb

I also noticed in situation one that sabnzbd docker wasn't able to stop properly. Maybe higher nice value to unrar process (being more friendly to other processes) might leave some air for it to pass the stopping command to the sabnzbd process. Just running 'docker-compose stop sabnzbd' had no effect. I simply had to flush the docker to make it stop.

Hope this clarifies a little bit.

Alright, so the message is too sensitive. I will try to fix this, maybe a longer delay.

This message was mostly introduced to check if this is a common problem, that unrar's cant be killed.

It appears to be fairly common for me. The archive is unpacked correctly. Ubuntu 18.04.1 LTS
I can provide the full unpack log if needed.

Jasonoff wrote: ↑February 6th, 2019, 8:30 am It appears to be fairly common for me. The archive is unpacked correctly. Ubuntu 18.04.1 LTS

Code: Select all

2019-02-06 08:20:04,224::INFO::[directunpacker:271] DirectUnpacked volume 44 for <HASH>c6dbfc5
2019-02-06 08:20:04,664::INFO::[directunpacker:183] Error in DirectUnpack of <HASH>c6dbfc5: <HASH>c6dbfc5.mkv - checksum error
2019-02-06 08:20:04,664::INFO::[directunpacker:385] Aborting DirectUnpack for <HASH>c6dbfc5
2019-02-06 08:20:07,067::WARNING::[directunpacker:414] Unable to stop the unrar process.

I can provide the full unpack log if needed.

Which version of SABnzbd?

Has to be 2.3.7 since this warning was only introduced then

safihre wrote: ↑February 7th, 2019, 7:45 am Has to be 2.3.7 since this warning was only introduced then

Correct

safihre wrote: ↑February 7th, 2019, 7:45 am Has to be 2.3.7 since this warning was only introduced then

Oh, and the warning has always been after 2 seconds? I had only seen the 0.2 second wait.

2 seconds is quite a long waiting time for a process termination. If even that does not work ... wow ...

Just had it on my Windows system too. Should think 2 seconds is enough..

Yeah, first time I posed in this thread was 2.404s And this most recent 2.403s Potential issue with UNRAR 5.50? I think the latest release is 5.61.

Guess I will just remove the warning, since it's only for an edge case that none of your are experiencing.

Why were there crc errors but the archive extracted ok?

Not sure. Probably something in unrar and we see it a lot more on dockers/unix than on Windows.

I can try updating unrar to the latest version.

Just throwing this out there. I was experiencing this on Windows regularly and it was messing with my Sonarr because even though the unrar would often complete successfully, if SAB was stuck on the unrar process, it wouldn't notify Sonarr to grab the file.

I was able to resolve this by manually replacing the UnRAR.exe file in C:\Program Files\SABnzbd\win\unrar\x64 (version 5.61) with the latest UnRAR.exe file from the 5.70.1.0 from the latest WinRAR beta (found under the WinRAR program files). This seems to have cured my errors for now. We'll see if it lasts.

Just so everyone knows, I also tried replacing the UNRAR.EXE from the latest beta release and it fixed my issue as well. It was happening to me like 100 times a day and now hasn't happened in 12 hours. Appears to have fixed it for me.