May 2, 20179 yr Hi. I'm using a Xeon E3-1240 v2 as my Unraid Server. I have Docker /NZBGet installed. After downloading, NZBGet proceeds to download a new file. Although it takes a few minutes to post process (Extract) a recently downloaded file. At times, after post processing previously downloaded files, it goes back to repairing, and I can see quite a few files in pp-queued. Want to know your experiences. Repairing at times takes 15 minutes for a 6 GB file. While the other files that were downloaded already are in pp-queued, waiting to be extracted. Does it really take this long? What am I missing? Edited May 2, 20179 yr by jang430 added info
May 2, 20179 yr Depends on the machine and the file, really. I've seen my old J1900 unRAID box take up to 30 minutes to repair a file, yet others repair in seconds. Generally only a few minutes at most. Some files even make the [email protected] choke. The main issue with nzbget is it uses the standard unrar executable, which isn't multi-threaded, and doesn't even top out one core. It's really quite slow. Edited May 2, 20179 yr by HellDiverUK
May 2, 20179 yr Author But I'm using Xeon E3-1240v2. Though I don't recall docker asking me how many cores I want to assign to it. So is Sab a better usenet client? Does Sab support multithreading? I used to use Sab before. People were saying nzbget is better because no need for post processing script. Does Sab still require post processing script? Sent from my LG-D855 using Tapatalk
May 2, 20179 yr I haven't use sab in years, I assumed it was still old, unsupported crap. I guess it's worth a try, doesn't take long to set up.
May 2, 20179 yr 2 hours ago, HellDiverUK said: Depends on the machine and the file, really. I've seen my old J1900 unRAID box take up to 30 minutes to repair a file, yet others repair in seconds. Generally only a few minutes at most. Some files even make the [email protected] choke. The main issue with nzbget is it uses the standard unrar executable, which isn't multi-threaded, and doesn't even top out one core. It's really quite slow. Actually you can easily replace nzbget's unrar with the latest unix executable from rarlab. This is very easy because you have an option in nzbget to specify the path to the unrar executable. BUT if you use the NZBGET within the Phaze plugin package you already get a relatively new version of unrar. Replacing that with the newest unrar 5.40 did not yield any big speed advantage. Also note that encrypted files take much longer to decompress (three times as much) than encrypted ones - maybe with encrypted files the J1900 is the bottleneck (I also got that processor) or unrar is just not very optimzied vor encrypted rar decompression (maybe it only uses one thread). Also on a sidenote: in order to have nzbget max out my 450mbit connection on the J1900 box (i get roughly 50mb/s download speed) i had to apply some of the nzbget speed tweaks which are mentioned on the nzbget help pages.
May 2, 20179 yr Author What do you consider encrypted files? Is that the same as me having SSL enabled? And files downloaded are called encrypted files? Noted and thanks for tip regarding Phaze's plugin. But come to think of it, Sab interface indeed suits me better. Will give it a try. Anyone know whether Sab requires script to tell Sonarr, Couchpotato that file has been successfully downloaded? Sent from my LG-D855 using Tapatalk
May 2, 20179 yr I only have 80Mb (the fastest available in non-cabled areas in the UK, pretty much), so the J1900 runs OK. I've not had any problems running nzbget on a Synology DS916+ (Intel N3710 which is similar to the J1900) either. I think I replaced the unrar executable in nzbget on Windows, when I ran a Win10 box as my server, and saw a little improvement, but it was hardly worth the bother.
May 2, 20179 yr 3 minutes ago, jang430 said: Anyone know whether Sab requires script to tell Sonarr, Couchpotato that file has been successfully downloaded? From memory, Sonarr and CP use the Sab API, so no scripts are required. I've never used any of those sab-to-media nonsense scripts, I don't know why they even exist, because Sonarr and CP handle direct comms with nzbget/sabnzbd natively.
May 2, 20179 yr Author Can anyone clarify the encrypted files mentioned above? Are they password protected files? Or files downloaded with SSL encryption enabled? Sent from my LG-D855 using Tapatalk
May 2, 20179 yr Community Expert 8 minutes ago, jang430 said: Can anyone clarify the encrypted files mentioned above? Are they password protected files? Or files downloaded with SSL encryption enabled? SSL is just about the transfer, not about the file. You get all sorts of things all the time using SSL and the result isn't encrypted, just the transfer.
May 3, 20179 yr 23 hours ago, jang430 said: What do you consider encrypted files? Is that the same as me having SSL enabled? And files downloaded are called encrypted files? Noted and thanks for tip regarding Phaze's plugin. But come to think of it, Sab interface indeed suits me better. Will give it a try. Anyone know whether Sab requires script to tell Sonarr, Couchpotato that file has been successfully downloaded? Sent from my LG-D855 using Tapatalk I am talking about rar files that are password protected - unfortunately these take about 3 times as long to unpack as non passworded rar files. I would not use SABnzbd, at least on my J1900 box i could never max out the 450mbit connection with sabnzbd (tops out at about 25mb/s with 20 connections). It seems that NZBGet ist much more efficient on slow machines (full 50mb/s even with only 10 connections). SSL did not make a difference on the j1900 box, neither with sabnzbd or with nzbGet - at least not that i could notice. Here some data for an passworded rar (encrypted): Statistic Data Downloaded size 41.6 GB Download speed 45.7 MB/s Total time 0:36:02 Download time 0:15:31 Verification time 0:00:00 Repair time 0:00:00 Unpack time 0:20:16 Here some data for an unpassworded rar (unencrypted): Downloaded size 43.2 GB Download speed 49.4 MB/s Total time 0:20:32 Download time 0:14:54 Verification time 0:00:00 Repair time 0:00:00 Unpack time 0:05:37 Edited May 3, 20179 yr by Videodr0me
May 3, 20179 yr It also partially depends on what storage you're using for the files and how much ram your system has. For the drive, is it SSD cache drive, or mechanical spinner cache drive, or are you using an array disk? I haven't had to repair a download in ages so the time taken for NZBGet to process a download seems to be nearly instant for typical under 20GB downloads (under a minute?) as I'm using SSD cache drive and my server has 128 Gig so nearly everything operates from RAM (files still in filesystem cache).
May 3, 20179 yr Author It also partially depends on what storage you're using for the files and how much ram your system has. For the drive, is it SSD cache drive, or mechanical spinner cache drive, or are you using an array disk? I haven't had to repair a download in ages so the time taken for NZBGet to process a download seems to be nearly instant for typical under 20GB downloads (under a minute?) as I'm using SSD cache drive and my server has 128 Gig so nearly everything operates from RAM (files still in filesystem cache).I use spinner. Although I have 8 GB on unraid machine, some are sued for VMs. I also assume other docker apps eat memory as well. Though I have no recollection of assigning memory to docker apps. In that case, how do Sab maximize use of Ram if it doesn't allocate specifically to the app? Sent from my LG-D855 using Tapatalk
May 7, 20179 yr On 3.5.2017 at 2:45 PM, BRiT said: It also partially depends on what storage you're using for the files and how much ram your system has. For the drive, is it SSD cache drive, or mechanical spinner cache drive, or are you using an array disk? I haven't had to repair a download in ages so the time taken for NZBGet to process a download seems to be nearly instant for typical under 20GB downloads (under a minute?) as I'm using SSD cache drive and my server has 128 Gig so nearly everything operates from RAM (files still in filesystem cache). The numbers i provide in my previous post are all with a 1tb ssd drive as both source and destination for the unrar.
May 7, 20179 yr Wow, I can't remember the last time I had extracts take that long. Then again you are on a substantially slower CPU system. The other day I had queued up 10 episodes of a newer series, each one being around 5GB in size (ranging from 4.4 to 5.7 GB) . Each one extracted at around 10 seconds. That would put a 50GB extraction around 50 seconds. On a 4.9GB file [ S***** S02E01 1080p WEBRip x264-SKGTV ] here's the timestamps from the end and begin of the process. Sat May 06 2017 16:44:03 Unrar: All OK Sat May 06 2017 16:43:54 Unrar: UNRAR 5.21 freeware Copyright (c) 1993-2015 Alexander Roshal Edited May 7, 20179 yr by BRiT
June 6, 20179 yr On 7.5.2017 at 8:07 PM, BRiT said: Wow, I can't remember the last time I had extracts take that long. Then again you are on a substantially slower CPU system. The other day I had queued up 10 episodes of a newer series, each one being around 5GB in size (ranging from 4.4 to 5.7 GB) . Each one extracted at around 10 seconds. That would put a 50GB extraction around 50 seconds. On a 4.9GB file [ S***** S02E01 1080p WEBRip x264-SKGTV ] here's the timestamps from the end and begin of the process. Sat May 06 2017 16:44:03 Unrar: All OK Sat May 06 2017 16:43:54 Unrar: UNRAR 5.21 freeware Copyright (c) 1993-2015 Alexander Roshal Let's do a very rough calculation 5GB/10s =500mb/s. This is only achievable in RAM with a fast CPU or from one SSD to another SSD. On my slow J1900 from SSD to the same SSD I get for unencryted rars 43.2GB/337s = 128mb/s... which is considering i read and write to the same SSD not bad at all. It would be interesting to see how fast your system is if the file is larger than your ram (which in your case is hard to achieve) or take the time until the ram cache is completely flushed to disk. It would be also cool if you could do an large encrytped unrar on your system, the data would maybe convince me to upgrade.... Edited June 6, 20179 yr by Videodr0me
June 6, 20179 yr Recommend using ssd for the repair activity. Repairing does a lot of I/O. If it is happening on a spinner it will be much slower. If it is happening on an array disk, it will be an order of magnitude slower than that! The final file should be configured to move to the file's final home, and not back to the same disk the dl and repair occurs. Saves cycles on the ssd (if using one) and avoids reading and writing to the same disk with a spinner. Look closely at the directory settings in the dl program you use to get the usage optimized.
Archived
This topic is now archived and is closed to further replies.