nzbget - binary newsgrabber

[hugbug]

Are all my files supposed to be called
(null)
(null)_duplicate1
(null)_duplicate2
(null)_duplicate3 etc??

No, they don't
I suppose these names were created by nzbget, not by a postprocess-script? Try a different nzb-file from a different source and report if it works.

[methanoid]

No, they don't
I suppose these names were created by nzbget, not by a postprocess-script? Try a different nzb-file from a different source and report if it works.

Seems to work on others.. musta been a rogue!

I really don't like the way it keeps NZB files when they have been completed and you have to delete them manually.. oh well... I guess I better hope the developers of the post processing scripts do all the things I still want to do.

I'll have to ask them how to fix such things like
WARNING PostProc:Unable to rename "/mnt/disk1/share/nzbget/nzb/Big Brother (UK) - 2008-06-20 - Big Ears Show 5.nzb" to .processed

It downloads fine now from web uploaded NZBs and ones copied via SMB to the NZB directory. I think I may miss the auto download of Newzbin bookmarks!

[hugbug]

Seems to work on others.. musta been a rogue!

Please send me a problem nzb-file for testing.

I really don't like the way it keeps NZB files when they have been completed and you have to delete them manually

Why bother? Delete them once a month .
I believe both perl-scripts delete them also.

[methanoid]

Why bother? Delete them once a month .
I believe both perl-scripts delete them also.

"I'll have to ask them how to fix such things like
WARNING PostProc:Unable to rename "/mnt/disk1/share/nzbget/nzb/Big Brother (UK) - 2008-06-20 - Big Ears Show 5.nzb" to .processed "

didnt work.. I'll investigate that... actually I have some good ideas for post processing scripts

[hugbug]

What you would want to do with .queued files? Just deleted them upon successful download/par-check? I could add an option to nzbget.

[methanoid]

What you would want to do with .queued files? Just deleted them upon successful download/par-check? I could add an option to nzbget.

Yeah that would be nice.... but someone (??) said

"I'm sorry to disappoint you, but I'm not planning any new features."

So I didnt ask any more..

I'm torn between two options now (not bad ones though).

I love SABnzbd for its usability but they won't improve the speed and said it's cos you write in C++ and they use Python that you can beat them for raw speed. I asked for a few other tweaks (because no program is ever perfect for you unless you write your own!!)

I love NZBget (yes, that WAS quick) because it's so quick. In many ways I am coming around to the idea of post processing by scripts, especially when ydrol's script uses PAR/RAR as lower priority processes. Nice script. But I still want more features in NZBget and I can understand your reluctance to add so many things. Have to also say that (touch wood) NZBget has been very stable!

I guess I'll have to make my mind up what I want.

[hugbug]

Yeah that would be nice.... but someone (??) said

"I'm sorry to disappoint you, but I'm not planning any new features."

he-he, I did not have plans, because I did not have feature requests
I have implemented most of requested features (auto-par, xml-rpc, web-interface, etc).

But unraring can be done via postprocess-scripts even better than from nzbget. If there were "libunrar", nzbget could provide some benefits over scripts (like a better progress-indication in par-check/repair).

they use Python that you can beat them for raw speed

Not just c++, but also:
- better algorithms like DirectWrite-feature (to avoid joining-step - reduce disk-io);
- many speed optimisations (after code-profiling);
- very thrifty memory usage.

To compare: nzbget is two (or three, don't remember numbers) times faster than Newsleecher, which is written in Delphi (as fast as c++).

But: you want write xml-rpc server in python, you use internal classes (part of python) and only implement your rpc-methods. In c++ you need to write web-server first, then write xml-parser and only then implement rpc-methods. If you got luck, you could find a suitable library on sourceforge, but it would have incompatible license or will not work on windows or will need other big libraries, which is not ported on optware yet.

------------

How about new (planned?) feature - categories:
- each nzb-file can be assigned to category;
- incoming-directory can have subdirectories (one level enough?); by uploading a nzb-file to the subdirectory, the file is automatically categorized. Like multiple blackholes in sabnzbd;
- for each category nzbget will create a subfolder under dst-directory;
- the ability to change category via web-interface;
Someone need that?

[neilt0]

How about new (planned?) feature - categories:
- each nzb-file can be assigned to category;
- incoming-directory can have subdirectories (one level enough?); by uploading a nzb-file to the subdirectory, the file is automatically categorized. Like multiple blackholes in sabnzbd;
- for each category nzbget will create a subfolder under dst-directory;
- the ability to change category via web-interface;
Someone need that?

I'm very happy with nzbget as it is, but it would be handy to have categories. This would be most useful in combination with integrating into nzbget an NZB downloader from Newzbin -- feed a NewZbin ID to nzbget via the web interface -- e.g. 3093573, nzbget would then download the NZB from NewZbin using their API, download the collection and unpack it into the appropriate category (e.g. TV).
That would also open the door for a third party to come up with an nzbdstatus like add-on (in fact nzbdstatus itself could easily support nzbget).

Anything more complicated than that and you may as well move the directories manually?

P.S. nzbget is currently downloading on my LinkStation at a rate faster than any of my Windows PCs can. It's fantastically fast!

[hugbug]

This would be most useful in combination with integrating into nzbget an NZB downloader from Newzbin

Yes, Newzbin-integration would be the next step.

Anything more complicated than that and you may as well move the directories manually?

I'm not getting what you mean

[neilt0]

If you have to monkey around with manually creating directories, it doesn't seem that much easier than dragging stuff manually?

Well I guess it's a bit easier. Um.

[methanoid]

But unraring can be done via postprocess-scripts even better than from nzbget. If there were "libunrar", nzbget could provide some benefits over scripts (like a better progress-indication in par-check/repair).

There IS a libunrar http://www.freshports.org/archivers/libunrar/

But I cannot see any ARM port of this

[hugbug]

If you have to monkey around with manually creating directories, it doesn't seem that much easier than dragging stuff manually?

The destinanion directories will be created automatically.
You need to create manually only the incoming subfolders and only if you want to put nzb-files in that folders manually.

If you upload files via web-interface, you just choose a category (via combobox probably). The same for newzbin - the category will be read from newzbin.

[hugbug]

There IS a libunrar http://www.freshports.org/archivers/libunrar/

It's interesting. Thanks.
I looked in Debian repository, in optware repository on rarsoft-site and did not found any libunrars. I thought there is none
I'll look into it.

[hugbug]

This version contains fixes for several bugs, including the bug, that broke the web-interface on CPUs with Big-Endian architecture (ARM, PPC, etc). Other bugfixes are not so important but you might want to update anyway.
See the full list of changes here.

The new version is already in optware-repository.

-----------------

Roadmap (methanoid ):
- I'm now working on category-feature;
- next (probably): newzbin-integration.

[methanoid]

Roadmap (methanoid ):
- I'm now working on category-feature;
- next (probably): newzbin-integration.

Thanks, can you make an iPhone version too?