nzbgetpp

This is a postprocessing script for nzbget. That is, after nzbget is done downloading things, this is a script that can be called to tidy up your download. Currently, we support:

unrarring files
removing unneeded files
categories
callbacks
logging
tests

NzbGetPP has a pre-defined callback for dewey, which will automatically place TV shows in the right place (and can be configured to rename things).

Other callbacks can include things like telling some other client to download the now-available file (more on this coming Real Soon Now) or updating a database collection.

Design

One of the major painpoints I've found with writing nzbget postprocessing scripts is they tend to be monolithic (bash) scripts and become really hard to reason about and extend. Testing them is also painful. This project has been designed to make it real easy to reason about it (OO design), see what is happening (logging) and test it works without actually downloading things (rspec).

Installing

Install the project via a gem or git/hub:

gem install nzbgetpp

.. or if that doesn't work, or you want the Git version:

NZBGETPP_INSTALL_PATH=~/src/nzbgetpp
git clone git://github.com/marcbowes/nzbgetpp $NZBGETPP_INSTALL_PATH
# or:
# curl https://github.com/marcbowes/nzbgetpp/tarball/master > $NZBGETPP_INSTALL_PATH
pushd $NZBGETPP_INSTALL_PATH
sudo rake install

Configuring

We look in two places for a config.rb file: either the default one we ship in support/, or in $HOME/.nzbgetpp/config.rb. This is a Ruby script that essentially lets you write code into lib/nzbgetpp.rb. We provide convenience configure do and install_callback(name) do methods, both of which have examples in the factory edition of the config.

The shipped version should "Just Work (TM)" in that it tries to pick the various binaries out of your environment. We make the assumption that you want to store stuff in $HOME/download/complete, but you can change this by setting storage_directory in the configure block.

The only possibly mysterious value is the scratch_directory. This is the directory we use to work on the nzb. It means that we don't step on anyone's toes as it is neither the initial destination, nor the final. That is, if you have some other script running (e.g. scanning for new files), this prevents race conditions (we do a mv at the end, which is atomic on the filesystem). That said, please make sure that storage_directory is on the same drive as scratch_directory, else you will incur a penalty when moving the files at the end.

Alternatives

Have a look at the nzbget page on post-processing scripts. At the time of writing, the two options are:

PPWeb is a Perl based Web solution for managing nzbget and comes with post-processing scripts.
Oversight is a full system but they provide their unpacking scripts in isolation. I was using this for a while and it works OK, but I found it slow and tricky to extend.

Contributing to nzbgetpp