Is there any way to increase the speed at which SABnzbd unpacks completed downloads? Right now SABnzbd downloads everything directly to my array (I don't have a cache disk yet) and I'm just impatient and want everything to go faster .
Once you have installed the SSD as a cache drive and set your sabnzb docker on the cahe drive and set then set your array share (final destination for the nzb results) to "use cache", it will unpack on the SSD and be immediately available as if it was already on the array. The file(s) actually get moved to the array based on the Mover schedule.
Sabnzbd Increase Download Speed
Download 🔥 https://bytlly.com/2yGB3p 🔥
Follow up question to this. I know the file would download to cache, then unpack to cache, so does that mean that if you had data moved to array daily, that you would need close to twice the download size of cache space for a particular download? As in even though the downloaded file gets deleted after it is unpacked, that space was used on cache, as well as unpacked file.. ?
Yes. While an unpack is in progress you will need space for both the packed and unpacked versions of the download. Once the unpack completes then presumably the app doing this will delete the packed version to free up the space it was occupying.
I have been curious about how well the Raspberry Pi, Pi 2 and Banana Pi perform at usenet downloading. I test 2 different usenet downloaders: NZBGet written in C++ and Sabnzbd written in python to see which performs better. This builds on my previous benchmark post Raspberry Pi 2 vs Banana Pi for throughput tests. These tests were made before using PAR2 multithreaded with Sabnzbd became possible.
The purpose of these benchmarks is to see how the Raspberry Pi, Pi 2 and Banana Pi Pro perform when downloading from usenet using popular downloaders Sabnzbd and NZBGet with and without SSL. I got access to a gigabit line which was connected to a 100 MBit switch in a rather complicated network structure so I decided to use that to push these little machines to the limit.
Overall and unsurprisingly, downloading without SSL is always faster than with SSL. NZBGet is consistently faster than Sabnzbd which is due to NZBGet being created in a more efficient programming language. Using NZBGet tweaks can yield a 50% download speed increase on the Raspberry Pi models though has no real effect on the Raspberry Pi 2 and Banana Pi. The Banana Pi was fastest in NZBGet which is unsurprising, despite the Pi 2 having a quad core 900 MHz CPU, it still shares the ethernet bus with the USB bus which could explain the slower speeds.
If anybody reading this has Google Fiber or a 1 Gbit connection they can test these units on then please get in touch with me by leaving a comment, I am very interested in getting some speed data on your setup.
The next benchmarks will be for file systems comparing ext4, NTFS and exFAT to examine the overhead on transfer rates. I also received an Orange Pi Mini recently so will be giving that a test as well while I wait for the Orange Pi Plus which is in the mail.
The information on this site is the intellectual property of the owner. Credit to other sources is provided where relevant. If you believe any information has not been sourced, please leave a comment and appropriate action will be taken.
Changes for v2.3.9 - v3.0.0About this new versionWe have been working for months to upgrade the SABnzbd code from Python 2 to Python 3.Although it might not sound like a big change, we had to rewrite almost every part ofthe code. We also included a number of new features, listed below.Big changes in 3.0.0 Python 3.5 and above are the only supported versions of Python. Cache handling is greatly improved, resulting in more stable speeds on some systems. Articles failing with CRC errors are now retried on other servers. SFV files, even obfuscated, will be used for renaming when there are no par2 files. Fully obfuscated RAR-sets with no verification files are detected and extracted. Built-in internet bandwidth test. Windows Service support was changed. The service will need to be reinstalled! Documentation: -as-a-windows-service The Windows installer is 64-bit only, for 32-bit please use the standalone package.Other changes since 2.3.9 Files inside an NZB that are fully identical are now skipped automatically. Folders of jobs that failed post-processing are renamed to _FAILED_. Blocking of unwanted extensions that are directly inside an NZB. In Python 3 OpenSSL 1.1.1 is used for Windows and macOS, as a result newsservers manually set to RC4-MD5 cipher can no longer connect. Documentation: -ciphers TLS1.3 support for newsserver connections. SABYenc, par2 and unrar are now required to start downloading. Growl-support was removed. The smpl skin was removed. Using the API with output=text to add NZB's will report the nzo_ids instead of ok. Queue-item labels are no longer part of the name but separated in API-property labels. API-calls tapi and qstatus were removed. On Windows only Multipar is available for repair. Linux tray icon support was improved. On Linux special permission bits are removed from files after download. macOS features such as the menu and notifications now use native code.Bugfixes since 2.3.9 Resolved potential security issue in FAT-filesystem check and Nice and IONice Parameters. More information: -9x87-96gg-33w2 Sample removal did not work if only 1 sample file was present. Crash on badly formatted RSS-feeds or readout during editing. Only really run pre-queue-script when it is set. Always report API paused status as a boolean. Automatic aborting of jobs that can't be completed would sometimes not trigger. Windows systems could enter standby state during downloading. Some errors thrown by unrar were not caught. Files and sockets were not always closed correctly. Unwanted extension check was overly aggressively deleting foldersUpgrade notices When upgrading from 2.x.x or older the queue will be converted. Job order, settings and data will be preserved, but if you decide to go back to 2.x.x your queue cannot be downgraded again. But you can restore the jobs by going to the Status page and running Queue Repair.
Changes for v2.3.9 - v3.0.0 Beta 4 Category was not parsed correctly when using addfile API-call. Restore nzbfile-parameter when using addfile API-call. Correctly detect filenames of existing files when retrying a job. Restore attributes when retrying a job that failed post-processing. Rename folders of failed jobs to _FAILED_ instead of leaving _UNPACK_.Changes and bugfixes since 3.0.0 Beta 2 Refactor of the code that handles adding NZB's and retrying jobs. Queue-item labels are no longer part of the name but separated in API-property labels. Using the API with output=text to add NZB's will report the nzo_ids instead of ok. Repeated API-arguments were handled incorrectly. Pausing the queue using the scheduler was broken. Updated Javascript libraries of Glitter and the config. Proper error-handling of bad email templates.Big changes in 3.0.0 Python 3.5 and above are the only supported versions of Python. Cache handling is greatly improved, resulting in more stable speeds on some systems. Articles failing with CRC errors are now retried on other servers. SFV files, even obfuscated, will be used for renaming when there are no par2 files. Fully obfuscated RAR-sets with no verification files are detected and extracted. Built-in internet bandwidth test. Windows Service support was changed. The service will need to be reinstalled! Documentation: -as-a-windows-service The Windows installer is 64-bit only, for 32-bit use the standalone package.Other changes since 2.3.9 Files that are fully identical are now skipped automatically. Linux tray icon support was improved. On Linux special permission bits are removed from files after download. macOS features such as the menu and notifications now use native code. In Python 3 OpenSSL 1.1.1 is used for Windows and macOS, as a result newsservers manually set to RC4-MD5 cipher can no longer connect. Documentation: -ciphers TLS1.3 support for newsserver connections. SABYenc, par2 and unrar are now required to start downloading. Growl-support was removed. API-calls tapi and qstatus were removed. The smpl skin was removed.Bugfixes since 2.3.9 Resolved potential security issue in FAT-filesystem check. Sample removal did not work if only 1 sample file was present. Crash on badly formatted RSS-feeds or readout during editing. Aborting jobs that can't be completed would sometimes not trigger. Windows systems could enter standby state during downloading. Some errors thrown by unrar were not caught. Files and sockets were not always closed correctly. Unwanted extension check was overly aggressively deleting folders
Changes for v2.3.8 - v2.3.9Duplicate job detection would not compare job namesPropagation delay could show even if it was not configuredIgnore Samples deleted all files of jobs containing the words Sample/ProofWarning "Unable to stop the unrar process" was shown too oftenDirect Unpack could hang forever on Unicode downloadsTest Download could fail if clicked on the icon instead of the buttonSeries Duplicate detection did not always work with Direct Unpack enabledAdding a job with non-existing category was not set to Default (*) categoryOnly delete completed jobs from history when using History Retention optionRenamed Server Load-balancing to Server IP address selectionLinux: remove sabnzbd.error.log file at start-up if it grew too largeWindows: double-click delay increased to avoid accidental pausingWindows: update MultiPar to v1.3.0.5Windows and macOS: update UnRar to 5.71 152ee80cbc