April 19, 201412 yr Author Ok....thx. Happy it isn't just me. Note to others: Moving from r13 on unraid 5 to r12 on unraid 6 crapped out the config file (error on load and wiped out when hit save in settings)...... live and learn (should have backed up). Yes, I'm afraid even though the plugin tries to do its best when upgrading, it's not an exact science and always wise to have a couple backup copies of the config files. I'd like to say that there will be a 64bit version of the testing branch soon, but unfortunately most of my kit is in storage pending a move and I doubt I'll have much chance over the next few months. When I finally get settled and have all my stuff setup, I'll upgrade my own system to v6 and then I'll have an opportunity to get back into things. With luck v6 will have moved forward in that time and hopefully so will the plugin architecture.
April 19, 201412 yr Yes, I'm afraid even though the plugin tries to do its best when upgrading, it's not an exact science and always wise to have a couple backup copies of the config files. I'd like to say that there will be a 64bit version of the testing branch soon, but unfortunately most of my kit is in storage pending a move and I doubt I'll have much chance over the next few months. When I finally get settled and have all my stuff setup, I'll upgrade my own system to v6 and then I'll have an opportunity to get back into things. With luck v6 will have moved forward in that time and hopefully so will the plugin architecture. No worries....system is back up an operational on v12. We appreciate what you do and understand you have other things going on at the moment.
April 25, 201412 yr Ok....thx. Happy it isn't just me. Note to others: Moving from r13 on unraid 5 to r12 on unraid 6 crapped out the config file (error on load and wiped out when hit save in settings)...... live and learn (should have backed up). Yes, I'm afraid even though the plugin tries to do its best when upgrading, it's not an exact science and always wise to have a couple backup copies of the config files. I'd like to say that there will be a 64bit version of the testing branch soon, but unfortunately most of my kit is in storage pending a move and I doubt I'll have much chance over the next few months. When I finally get settled and have all my stuff setup, I'll upgrade my own system to v6 and then I'll have an opportunity to get back into things. With luck v6 will have moved forward in that time and hopefully so will the plugin architecture. Is there anything we can do to assist in the interim?
April 27, 201412 yr If installing to an SSD outside array, would the proper NZBGet location be: /mnt/appdisk/nzbget or /usr/local/nzbget ____ Also, is there a way to get nzbget to auto-create the category folders I wish to use in conjunction with NZBDrone and Couchpotato?
April 28, 201412 yr If installing to an SSD outside array, would the proper NZBGet location be: /mnt/appdisk/nzbget or /usr/local/nzbget ____ Also, is there a way to get nzbget to auto-create the category folders I wish to use in conjunction with NZBDrone and Couchpotato? /mnt/appdisk /usr/local is the USB drive i believe
April 28, 201412 yr If installing to an SSD outside array, would the proper NZBGet location be: /mnt/appdisk/nzbget or /usr/local/nzbget ____ Also, is there a way to get nzbget to auto-create the category folders I wish to use in conjunction with NZBDrone and Couchpotato? /mnt/appdisk /usr/local is the USB drive i believe /usr/local is a Linux OS folder. In unRAID, that folder is in RAM and so will not survive reboot. If by USB drive you mean the flash drive that unRAID boots from, that is /boot Assuming you have actually mounted the SSD and its mountpoint is /mnt/appdisk, then you would use that. But I notice you have some other posts where you are getting a path does not exist error, so perhaps that is not a good assumption.
April 28, 201412 yr If installing to an SSD outside array, would the proper NZBGet location be: /mnt/appdisk/nzbget or /usr/local/nzbget ____ Also, is there a way to get nzbget to auto-create the category folders I wish to use in conjunction with NZBDrone and Couchpotato? /mnt/appdisk /usr/local is the USB drive i believe /usr/local is a Linux OS folder. In unRAID, that folder is in RAM and so will not survive reboot. If by USB drive you mean the flash drive that unRAID boots from, that is /boot Assuming you have actually mounted the SSD and its mountpoint is /mnt/appdisk, then you would use that. But I notice you have some other posts where you are getting a path does not exist error, so perhaps that is not a good assumption. So the reason I asked is because when discussing NZBDrone, it was recommended I point the install directory to /usr/local/nzbdrone and config directory to /mnt/appdisk/nzbdrone/appdata. This would force nzbdrone to re-install on each boot to make sure it’s a clean in addition to running on RAM. Reference this post (http://lime-technology.com/forum/index.php?topic=32612.msg303974#msg303974) I realize that since nzbget doesn't have a separate config directory it probably should not be installed to /usr/local as nzbdrone was. I know the SSD is mounted outside the array but the issue I'm having is applications are not able to create new folders on that drive. For example I wanted to setup the folder for tvshows to link between nzbget and nzbdrone but it's not creating or I'm not aware of the proper way to create it. Through another recommendation, once I get the chance tonight, I'll config samba for the appdisk so I can browse/create folders through windows explorer.
May 22, 201412 yr Author Okay, for those of you running the 64bit version of my nzbget plugin and who have been wanting a 64bit version from the v13 testing branch, I've created one. It's been created from the latest testing release : 13.0-testing-r979 As always, backup your configs. I've tried in the past to cater for all eventualities, but can't be sure it won't wipe out your precious settings. No biggie, but I've switched to using a pre-built libpar package. Previously I was using my own which was patched with two specific nzbget patches. Now I'm using an x86_64 version via pkgs.org. Suggest you; 1) update the plugin first so that it installs the alternative libpar package 2) switch to testing branch and it should offer an update to the nzbget application If this works, I'm going to modify the plugin so that it falls in line with unRAID v6 plgman so that it can be installed via the Extensions tab and the plugins page will show the nzbget plugin and provide a way to update from there instead. Please report issues here. Thanks, overbyrn
May 22, 201412 yr Cool beans! Does the new libpar still include the nzbget patches? Sent from my Moto G using Tapatalk.
May 22, 201412 yr Author Cool beans! Does the new libpar still include the nzbget patches? Sent from my Moto G using Tapatalk. That's the thing. No, libpar does not include the patches. Now I imagine Hugbug might see this and respond and I'd be interested to have his take. His README and INSTALL text files with nzbget source say the patches are for slow NAS systems, which I'm prepared to gamble do not really cover the average unRAID system these days, especially on the assumption we're talking 64bit capable systems. However, his docs also say it's strongly suggested the patches go in. I'd like some real-world tests before doing anything else. You have a fast connection and I'm sure will soon find a problem if one exists
May 22, 201412 yr I'd have to switch to 6, but I'll look at that tomorrow - I was only waiting on nzbget to make that switch, so... Sent from my Moto G using Tapatalk.
May 23, 201412 yr Okay, for those of you running the 64bit version of my nzbget plugin and who have been wanting a 64bit version from the v13 testing branch, I've created one. It's been created from the latest testing release : 13.0-testing-r979 As always, backup your configs. I've tried in the past to cater for all eventualities, but can't be sure it won't wipe out your precious settings. No biggie, but I've switched to using a pre-built libpar package. Previously I was using my own which was patched with two specific nzbget patches. Now I'm using an x86_64 version via pkgs.org. Suggest you; 1) update the plugin first so that it installs the alternative libpar package 2) switch to testing branch and it should offer an update to the nzbget application If this works, I'm going to modify the plugin so that it falls in line with unRAID v6 plgman so that it can be installed via the Extensions tab and the plugins page will show the nzbget plugin and provide a way to update from there instead. Please report issues here. Thanks, overbyrn Seems to work fine. I updated with no issues.
May 23, 201412 yr There is a cancel patch, allowing to interrupt a par-job. That is mostly for slow systems, where the repair can take hours. And there is a bugfixes patch, which fixes few bugs in libpar2. All of them were found on real par2-files. Without these fixes libpar2 can crash on certain par2-files, crashing NZBGet. The par2-project is abandoned by its authors but the Debian/Ubuntu maintainers have their own fork, which is essentially the last version of original libpar2 + few fixes. The last version 0.4 from Debian/Ubuntu already includes all patches from NZBGet. Other Linux distributions tend to switch to Debian/Ubuntu fork.
May 23, 201412 yr Author Have updated the testing branch for version 5 plugin to 13.0-testing-r979 also.
May 23, 201412 yr Have updated the testing branch for version 5 plugin to 13.0-testing-r979 also. Cool! Erm... I updated and nzbget now won't start (no web interface) and I get this: :'(
May 23, 201412 yr This doesn't look good? root@MICRO:/usr/local/nzbget# nzbget nzbget: error while loading shared libraries: libgnutls.so.26: cannot open shared object file: No such file or directory
May 24, 201412 yr Author This doesn't look good? root@MICRO:/usr/local/nzbget# nzbget nzbget: error while loading shared libraries: libgnutls.so.26: cannot open shared object file: No such file or directory Fixed. You'll need to manually update the version of nzbget as the plugin won't know what to do. Two steps; 1. Delete file 'nzbget-13.0-testing-r979-i486-1.txz' from /boot/config/plugins/nzbget 2. From command line type; /etc/rc.d/rc.nzbget updateapp Go back into nzbget plugin webgui page. All should be well.
May 24, 201412 yr Thanks, overbyrn. I got it up and running, but a couple of things seem to have broken -- may be user error? I can't work out where it's getting nzbget.conf from by default (or the default passwords -- the ones listed in the nzbget doc don't work), so it works if I force the conf with: /usr/local/nzbget/nzbget -D -c /mnt/cache/unraid_apps/nzbget/nzbget.conf But if I start from the settings interface (or at boot) it defaults back to the original conf. Secondly, the plugin version (online) is showing as "UNKNOWN". And finally, does the 6.0 x64 version of nzbget that you built have version 0.4 of the libpar2 library? I'm not sure if it was made clear earlier, but 0.2 without patches has fatal bugs that will definitely crash nzbget (e.g. when a file is missing during repair, a common occurrence). Thanks again for your work on this. Cheers! Neil.
May 24, 201412 yr Author Thanks, overbyrn. I got it up and running, but a couple of things seem to have broken -- may be user error? I can't work out where it's getting nzbget.conf from by default (or the default passwords -- the ones listed in the nzbget doc don't work), so it works if I force the conf with: /usr/local/nzbget/nzbget -D -c /mnt/cache/unraid_apps/nzbget/nzbget.conf But if I start from the settings interface (or at boot) it defaults back to the original conf. Secondly, the plugin version (online) is showing as "UNKNOWN". And finally, does the 6.0 x64 version of nzbget that you built have version 0.4 of the libpar2 library? I'm not sure if it was made clear earlier, but 0.2 without patches has fatal bugs that will definitely crash nzbget (e.g. when a file is missing during repair, a common occurrence). Thanks again for your work on this. Cheers! Neil. Neil, I'll look into the issues you mention - but not now. As for libpar2, I'm currently in the process of switching all of my nzbget builds to use the current libpar2 0.4 source. This is by no means a simple task as I have four streams (32bit 12.0 stable, 32bit 13.0-testing, 64bit 12.0 stable, 64bit 13.0-testing) to recompile. On top of this I need to create new libpar2 packages for each unraid branch ensuring each maintains the libs in the correct location. eg. unraid v5 uses /usr/lib whereas unraid v6 uses /usr/lib64. I *could* just ignore that and let 64bit reside in /usr/lib, but that's messy and does not reflect the correct paths. It also means I have to trash the existing 12.0 stable I built for 64bit v6 unraid as that did look for libpar in /usr/lib and not /usr/lib64. I have to do all of this without impacting the live versions. I should have everything sorted in a few hours, but the downside is you and everyone else will probably get a notification of update to the plugin as I'll have to work out some way to distribute the newly built libpar2 0.4 and nzbget packages. Ever wish you hadn't started something...
May 24, 201412 yr OK, no worries. I have a workaround for now. I think I can probably fix my startup issues if you can tell me where nzbget looks for the .conf by default, I think. There's no rush though, as I know how to get it going. Cheers, Neil.
May 24, 201412 yr Author OK, no worries. I have a workaround for now. I think I can probably fix my startup issues if you can tell me where nzbget looks for the .conf by default, I think. There's no rush though, as I know how to get it going. Cheers, Neil. I'm not sure how you got into the position you're in. That being said, here's some general information so that hopefully we can collaborate on fixing your problem. The config file should reside at the location you have your installation at. So if your "NZBGet Location" was /mnt/cache/apps/nzbget, then you should see nzbget.conf at this location and it's this which is loaded upon a start. This is your primary config file and contains all your personal settings. Whenever the plugin does an update to the app (NOT the plugin itself), it ALWAYS makes a copy of your live nzbget.conf to a backup copy called nzbget.conf.save located at /boot/config/plugins/nzbget. There is also a ConfigTemplate : /usr/local/nzbget/nzbget.conf. This file comes with nzbget and is used by nzbget as a reference config file. This file should never be modified from the original. NZBGet uses this file as a reference for what config options are correct for this particular version of NZBGet. I hope I get this right (sorry to HugBug if I don't), but on the assumption that a config option has changed between versions or new one added etc, NZBget uses the template in conjunction with your existing nzbget.conf file to deal with any discrepancies. You already know that going into Settings and hitting save will usually fix this. I'm assuming HugBug does some magic involving the template to tweak your live config to match the valid config options for the version of NZBGet you are running. When switching from Stable to Testing, you're going to get a new ConfigTemplate and we can pretty much assume some changes will have taken place. When you fire up the new testing branch, your live config file won't have been touched and NZBGet should use the template to work out what config options may be depreciated etc. and it should handle any changes, but there's always a margin for error. Either way, the application only cares to read one config file and that's as mentioned above. If you're seeing errors and having to resort to pointing it at a version you have stored on flash, then something really weird is wrong. Obviously at this point I'd recommend starting over with regard to the plugin. If it were me, I'd stop NZBGet if it was running, I'd take a backup of nzbget.conf from my NZBGet Location and also a backup copy of the one I have on my flash and I'd store them elsewhere. Then I'd delete ALL nzbget.conf files followed by the nzbget plugin and application; rm -rf /usr/local/nzbget rm -rf /boot/config/plugins/nzbget rm /etc/rc.d/rc.nzbget rm -rf /usr/local/emhttp/plugins/nzbget rm /var/run/nzbget.pid (this probably wont exist) rm /var/log/plugins/nzbget Then I would re-install the plugin via installplg /boot/config/plugins/nzbget_overbyrn.plg In the NZBGet unRAID WebGui, set it back up to point to the original location and start it. It should create a new working copy of the nzbget.conf file and start without error. If it does, then stop it, copy over your old nzbget.conf file to the same location and try starting it again. If it doesn't then it's really not happy and I'd say you'll need to start with a fresh config.
May 24, 201412 yr Thanks. I had already deleted the conf and restored a backup, but there are some steps you listed I hadn't done, so I'll do all that shortly. Cheers. Sent from my Moto G using Tapatalk.
May 24, 201412 yr Author Thanks. I had already deleted the conf and restored a backup, but there are some steps you listed I hadn't done, so I'll do all that shortly. Cheers. Sent from my Moto G using Tapatalk. Did ya fix it? I've now successfully tested nzbget for 32 / 64bit unRAID variants and will push out an update soon where libpar2 0.4 is used throughout. I've got a stable - if albeit temporary - slack 13.1 & 14.1 build environment now which should mean I can crank out updates from time to time.
May 24, 201412 yr I've been tied up, but will take a look later (UK) time. Sent from my Moto G using Tapatalk.
Archived
This topic is now archived and is closed to further replies.