SABnzbd Forums

Twice in the last 48 hours, I've received the above message. .. ver. 2.3.7 on Windows 10. I've never seen this before: what does it mean? Shows from Sonaar seem to d/l ok and they are in their expected locations. Is this message something I can ignore or is it a portent of doom? An inexpert scan of the logs suggests that a show may be grabbed, the process encounters an error/errors, so the show is grabbed from another newsgroup... pardon my ignorance!

+1

Noticed this a couple times now.

2019-01-28 22:19:35,642::INFO::[directunpacker:183] Error in DirectUnpack of <HASH>2b09979: <HASH>2b09979.mkv - checksum error
2019-01-28 22:19:35,642::INFO::[directunpacker:385] Aborting DirectUnpack for <HASH>2b09979
2019-01-28 22:19:38,046::WARNING::[directunpacker:414] Unable to stop the unrar process.

That feature/warning was introduced in SAB 2.3.7: "Send graceful Quit for UnRar first when aborting". It was introduced for a niche case, so I'm surprised (but not worried) that you see that warning.

Let's keep an eye on it.

See https://github.com/sabnzbd/sabnzbd/comm ... 030768d264

In your task manager, do you see "Unrar.exe" somewhere in the Details tab?

Maybe the check was too strict :/

I'll check if it happens again ( I've rebooted since this occured!)...

I should have mentioned I am using Linux. Ubuntu 18.04.1 LTS.

This is happening to me too.
This is running the LSIO sab docker on Ubuntu 16.04 and it started out of the blue a couple of days ago.

I have the log but link it since I'm new.

Thanks

hacktek wrote: ↑January 31st, 2019, 12:17 pm This is running the LSIO sab docker on Ubuntu 16.04 and it started out of the blue a couple of days ago.

It's too soon to say if it's happening to me regularly, but it happened to me yesterday after I first set it up. I'm also running the LSIO docker image, although on Mint 19.1 (Ubuntu 18.04 based). The unrar processes were hung so badly under the container I couldn't kill them off. I had to reboot the machine to get rid of them.

It's a bug inside unrar we think.
What locations are you unpacking to? Are they shares on a network-drive?

I've got the same issue.

I am able to kill the process by docker rm -f [dockername] or by killoff the process of the docker. Killing off the unrar process will just restart the unrar process to create 100% disk usage. After starting the sabzbd docker unrar creates 100% disk usage again. There were some untangled processes within sabnzbd but removing doesn't resolve the issues.

Disk is a usb 5T disk directly attached
Sabnzbd running on docker: build_version": "Linuxserver___io version:- 153 Build-date:- January-26-2019-05:38:10-UTC

https://imgur_______com/a/eZDbxHf (remove '______' to see the node exporter output) The peaks are stopping and starting the docker.

So ... did this problem (unrar still running) already exist and is the new Warning just noticing it, or does the new SABnzbd method cause the problem?

I noticed it this week multiple times. Not using the new method. I started sabnzbd again but without the 100% disk load. There was a big queue of downloads and it was performing as expected.

After removing the big queue (select 'all' button and then delete) I noticed the "Unable to stop the unrar process.". Maybe deleting queue creates this error.

safihre wrote: ↑February 3rd, 2019, 5:41 am It's a bug inside unrar we think.
What locations are you unpacking to? Are they shares on a network-drive?

In my case, yes. Incomplete/complete folders on HDD on computer, Sonaar then handles move to a shared folder on a NAS.

I added a big queue, didn't cancel any items on the queue but resulted in many (8 to 9) "Unable to stop the unrar process." on average hourly. Seems like if you let it run eventually unrar issue will resolve. At least in this download of 50x (300GiG) queue.

https://imgur.com/a/SXcPvAb

Before to this download sesssion I noticed Sickrage is also having a high read/write from the complete folder to the final destination. Sabnzbd docker was forced off during this observation. IOTOP revealed which process is doing the actual read/writing. I'm going to place the sabnzbd complete/incomplete on a separated disk to see if disk performance has an influence. I'm downloading with an average of 24MB/s (Sabnzbd indicator). Could be that the download vs. unrar/copy creates a huge backlog of IO by Sabnzbd and Sickrage. This still isn't an explanation why unrar process is hard to kill off.

Before separating complete/incomplete from final destination I should test switching off Sickrage and do the same download queue.

So the only new thing is that we have this extra warning.
What we now have to figure out if it is right, so @djieno: after the queue is done, does it still show unrar processes? From what you say this is actually the case, that you can only kill it by killing the docker.
Although the 100% disk usage might be correct, if it's actually unpacking.
Still trying to figure out if anything is actually going wrong.