Sounds really really great
I think it's fantastic that you guys have gotten some new ideas and some drive to implement them to the project.
Personally I have been neglecting development on nzbget for quite some time for the following reasons (here comes the lame excuses):
First of all my personal setup is actually rather stable. It almost never crashes and from time to time runs for more than a week without problems. Also some of the bugs which remains with the code seems to be related to how the newsservice performs, and since my newsservice performs rather well I would need to go looking for a bad newsservice to approach these problems - and I really don't need the extra D/L bandwidth (my epia server can't use my entire bandwith at current time).
The second and more important reasons is that I'm spending my free time coding on a bigger project that I intend to make a living off sometime in the future - this means that this has high priority and I'm unlikely to spend much time extending the features of the nzbget in the near future.
I'm open to suggestions as how to proceed from here
) People could do patches and these could be tried out, I could give developer/admin rights to one, more, or whomever wanted this, or somebody could take over as admin for the project?
PS. In relation to Nibor's remarks:
* "Change queue with client" - I had thought about implementing this, but never got to it, it seems. Anyhoop it shouldnt be a big problem to implement.
* "when an nzbfile will be placed at top in the queue, it should start to download that one directly" - this was actually one of the first things I tried to look into when I took over the project from siddy. But as I discovered, getting this functionality demands some refactoring of the code. Currently the download part of the code only tracks all the files which a news-download consists of for the current downloading .nzb-file.