No, they don't :)Quote:
Originally Posted by methanoid
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.
Printable View
No, they don't :)Quote:
Originally Posted by methanoid
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!Quote:
Originally Posted by hugbug
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!
Please send me a problem nzb-file for testing.Quote:
Originally Posted by methanoid
Why bother? Delete them once a month :).Quote:
I really don't like the way it keeps NZB files when they have been completed and you have to delete them manually
I believe both perl-scripts delete them also.
"I'll have to ask them how to fix such things likeQuote:
Originally Posted by hugbug
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
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 (??) saidQuote:
Originally Posted by hugbug
"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. :o
he-he, I did not have plans, because I did not have feature requests ;)Quote:
Originally Posted by methanoid
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).
Not just c++, but also:Quote:
they use Python that you can beat them for raw speed
- 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?
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).Quote:
Originally Posted by hugbug
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!
Yes, Newzbin-integration would be the next step.Quote:
Originally Posted by neilt0
I'm not getting what you mean :confused:Quote:
Anything more complicated than that and you may as well move the directories manually?
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.
There IS a libunrar http://www.freshports.org/archivers/libunrar/Quote:
Originally Posted by hugbug
But I cannot see any ARM port of this :(
The destinanion directories will be created automatically.Quote:
Originally Posted by neilt0
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.
It's interesting. Thanks.Quote:
Originally Posted by methanoid
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.
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.
Thanks, can you make an iPhone version too? ;)Quote:
Originally Posted by hugbug