nzbget

I am having an issue with scheduled tasks not happening at local time. I need to enter scheduled times at GMT. I bet I'll have to go and edit them once we switch to daylight savings time too. Not a big deal, but I didn't have that problem with needo's docker back when I used that. If this is an acknowledged/known issue, please consider listing it in the top post as a known defect. And if you fix this, please make an announcement or update the top post. Thanks! This is an issue with the version of NZBGet in this container. Try going to settings - logging - TimeCorrection I assume this container uses binary from universal linux installer. That binary is compiled using uClibc, which reads time zone information from /etc/TZ or from environment variable TZ. Expected format for TZ: http://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html Examples: http://lists.uclibc.org/pipermail/uclibc/2002-August/004010.html If you can set the env. variable TZ properly before executing NZBGet it will know correct time and TimeCorrection will not be needed. UNRAID probably uses a different way to configure timezone, which NZBGet (uClibc) doesn't support. It's very unlikely that this issue will be fixed in uClibc (=NZBGet).

Can you please test the speed when installed using Universal installer for Linux? The installation is easy, consists only of few steps; the files are installed into one folder; after the test you can delete the directory and nothing remains. Since the installer version isn't related to docker (and this forum is for docker) may be it would be better to continue discussion on NZBGet forum or you can write me at nzbget@gmail.com if you don't want register on forum there. The fast download speed is one of the main priorities and I'd like to fix that problem for you if possible.

Looks very clean. I've noticed one thing - it lists both OpenSSL and GnuTLS in the dependencies (libssl-dev libgnutls-dev). NZBGet choose one during configure-step and doesn't require both. I recommend OpenSSL.

SVN revision numbers are part of the testing releases names (like nzbget-testing-14.0-r1070). NZBGet users are familiar with that numbers and will have no problems with them. Tags in contrary are strangers since they are never mentioned on the forum or in NZBGet docs. I appreciate your work, guys, in providing NZBGet packages for unRAID users. If you have any questions or suggestions please contact me at nzbget@gmail.com or via NZBGet forum. I will monitor this thread too but I may miss something.

No, at least not in the near future. I've heard about docker for the first time about a month ago. I'm not familiar with this technology at all and have no idea how much efforts it will take to provide the package and support for it. Revision numbers are much better. They even allow user to try a version which was not released as testing yet. Or quickly test a bugfix. And I don't want to clutter the "tags"-subdirectory with testing releases. Making it work with release numbers shouldn't be that much trouble for you?

Debian/Ubuntu version of libpar2 includes all patches required for v12 or v13. It doesn't have the new patch for v14 yet.

I fully understand the idea of providing robust (stable) packages. I also understand the wish of some users to have the latest and greatest (with bugs). A good compromise was discussed in this thread - to let the user pass a revision number to fetch from svn (trunk). This unfortunately will not help in the current case because of a patch required for libpar2. Still it's generally a good idea for the future. It's very rare for NZBGet to need new dependencies and the patches for libpar2 are also rare (the previous was about two years ago). BTW v12 and v13 require the same libpar2 - either official 0.2 + patches or 0.4 from Debian/Ubuntu (which already includes the patches).

I appreciate your sense of humor

Guys, let me clarify the things. That's probably an unfortunate wording that had lead to misunderstanding. Yil is not the author of par2 library, neither the author of this feature or any other single line of code included in NZBGet. What was meant in the phrase is that Yil has made a research of par algorithm and of source code of par library. He has published his findings on NZBGet forum and his idea (skipping the scan of undamaged files) was implemented by me in the new feature. The required patch for libpar2 was made by me as well, similar to other patches made by me years ago, which are already included in the Debian/Ubuntu fork of libpar2. The new patch is actually very small, it's just making one of the function "virtual" allowing NZBGet to intercept the call and perform verification instead of letting libpar2 doing it. Plus another small change, not related to this. The feature is complete, it was tested by few forum members and is now available for testing for all other users in the new testing release. Yil has many ideas. Some of them can find their way into NZBGet. We will see. As for waiting for libpar2 upstream to review the patch - this will never happen. The libpar2 project is dead for years. I'm glad the Debian/Ubuntu team has taken the maintenance but they don't do more than integrating the submitted patches. And it's not a coincidence that the maintainer of Debian/Ubuntu fork of libpar2 is the same person who maintains NZBGet for Debian/Ubuntu. par2cmdline vs libpar2: please don't confuse that two packages. NZBGet doesn't use par2cmdline, but only libpar2. There are not so many software which use libpar2. I know only one (in addition to NZBGet) - gpar (gnome frontend). There is no risk in integrating the new patch into your version of libpar2 because NZBGet is most likely the only program in your repository depending on it (I don't think unRAID has gpar and if it uses gnome at all, I don't know). -- hugbug