nznzb 0.36
==========

(WARNING: this is a lot more experimental than the older code)

The old nznzb created multiple download threads and downloaded
what appeared to be one file per download thread. ie. if the 
NZB file consisted of 28 rar parts then , then blah.rar was
the first thread, blah.r01 was the 2nd and so on.

This new version of nznzb is redesigned so that the multiple 
'segments' that make up each file (or rar part for most people)
are parallelised so that it looks like you are downloading a 
single file at a time ... at seemingly high speed. So in reality,
it's usually downloading multiple segments of the one file at a
time.

This has the benefit that we can quickly download a multipart
rar nzb in the order in which unrar would usually load the rar
parts. ie. download all of blah.rar first, then blah.r01 and so
on.

This means we can kick unrar off just after the first rar is
downloaded. Normally, unrar would abort when it gets to 
loading the next part in the sequence (eg. blah.r01). But
unrar can be run with a -vp option which makes it pause and
prompt the operator between decoding each rar part. I've added
code which works like a mini-expect mechanism to essentially
work as a wrapper around unrar and as each new rar part is
downloaded it presses the 'C' key to tell unrar the next part 
is ready.

This way you can dynamically unrar a file as it downloads
 (so long as there are no errors in the rar parts). If you're
downloading some kind of media file and your connection is 
fast enough, you can actually watch or listen to the media
as its downloading.


Usage
=====

You need a ~/.nznzbrc file . Mine looks like:

# comments
#server = east.usenet-news.net
server = eu.usenet-news.net
port = 119

user=myusername
pass=blahblah

threads=7

extract_to = /media

auto_unrar = 1
#######

I think if you leave out the user and pass it attempts to connect
to your usenet host without requiring a password. server and port
are self explanatory. threads is the number of parallel download
threads (I think I set a limit of 15). And if you want to 
automatically unrar stuff as it downloads, you need to set
'auto_unrar' to '1'. By default unrar will extract to your current
directory but you can specify 'extract_to' and some directory and it
will extract there instead.

Compiling
=========

 gcc -o nznzb -lpthread nznzb.c

Installing
==========

 Copy the 'nznzb' file to somewhere in your path.

Quickstart
==========

1. create a ~/.nznzbrc . Read the comments earlier about what
   to put in it. Make sure the path to the special unrar is correct
2. cd to a diectory with a fair bit of free space
3. nznzb somefile.nzb

Perhaps watch it until the first rar file has downloaded, then 
ps -ef to see if unrar has launched, and hopefully you should have an
output file in your current directory or your 'extract_to' directory.
You should then be able to start playing the media file that the rar parts are made of.

Bugs/Features
=============

- Since I started writing this thing I hav occasions when all the socket
  connections to my usenet host die (or more importantly fgets returns an error).
  There is quite a bit of logic to try to reconnect again and go ... but 
  I'm not 100% sure its the greatest solution. Still working on it
- Change DEBUG to 0 in the source file to get more debug output
- It will tend to resume (to some degree). If you have downloaded blah.rar,
  blak.r00, blah.r01 , and then ctrl-c out and start again, it will start to 
  download blah.rar, but work out it's already got it while reading the first segment.
  ie. it'll download a bit of each of those files again, before eventually
  getting to blah.r02. The stats about the ETA and transfer speed will be wildly
  wrong ... but it will finish OK.
- The mini-expect code needs to be a bit smarter. Has a horrible buffer
  limit that is annoying.
- The uudecode code is disabled. use the older (< 0.3) versions to get
  uuencoded stuff
- I don't think this version will handle multiple nzb files specified on the
  command line. 
- Each download thread generates a file called 'thread_....', and each file
  segment will end up with a part_x_y file. You can generally do a
   rm thread_* part* 
  before starting nznzb again
