This release focuses on portability. Settings can now be stored in an nzb.ini file in the program directory, meaning nzb can be used without installing it on the system and configuring it, and it doesn’t have any external dependencies.
SSL support has also been added which is very useful in mobile situations where the network may not be trusted and your credentials should be protected by encrypting the traffic. To utilize the SSL support you need to have a Usenet provider that supports SSL, like Giganews.
I like this a lot. Excellent feature and looks nice too. Would like it to use less cpu on my XP SP2 machine though.
How is the CPU usage compared to other nzb/usenet clients? Decoding the yEnc files will always use some CPU, and the faster your network connection the more decoding will happen at a given time.
The cpu usage is a lot higher than Grabit or NZB-O-Matic. And this is at times when it is not decoding. I have a fairly old PC (athlon XP 2000) and it makes it hard to multitask when nzb is downloading. Which is a shame because apart from that issue it is the nzb client I like best.
Ok. I’ll try to do some benchmarking at some point and find the cause of the cpu usage. Might be a Qt related problem.
0.1.6 compiles no problem, but with 0.1.7 I get this:
g++ -c -pipe -O2 -march=athlon-xp -pipe -D_REENTRANT -Wall -W -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_L
IB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtG
ui -I/usr/include/qt4/QtXml -I/usr/include/qt4 -I. -I. -o main.o main.cpp
g++ -c -pipe -O2 -march=athlon-xp -pipe -D_REENTRANT -Wall -W -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_L
IB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtG
ui -I/usr/include/qt4/QtXml -I/usr/include/qt4 -I. -I. -o mainwindow.o mainwindow.cpp
mainwindow.cpp: In constructor ‘MainWindow::MainWindow()’:
mainwindow.cpp:71: error: no matching function for call to ‘QTableWidgetItem::QTableWidgetItem(QIcon, const QString)’
/usr/include/qt4/QtGui/qtablewidget.h:68: note: candidates are: QTableWidgetItem::QTableWidgetItem(const QTableWidgetItem&)
/usr/include/qt4/QtGui/qtablewidget.h:67: note: QTableWidgetItem::QTableWidgetItem(const QString&, int)
/usr/include/qt4/QtGui/qtablewidget.h:66: note: QTableWidgetItem::QTableWidgetItem(int)
mainwindow.cpp:78: error: no matching function for call to ‘QTableWidgetItem::QTableWidgetItem(QIcon, const char [11])’
/usr/include/qt4/QtGui/qtablewidget.h:68: note: candidates are: QTableWidgetItem::QTableWidgetItem(const QTableWidgetItem&)
/usr/include/qt4/QtGui/qtablewidget.h:67: note: QTableWidgetItem::QTableWidgetItem(const QString&, int)
/usr/include/qt4/QtGui/qtablewidget.h:66: note: QTableWidgetItem::QTableWidgetItem(int)
make[1]: *** [mainwindow.o] Error 1
Any ideas? Using Gentoo Linux.
nzb requires Qt 4.2 or higher. Your error is due to a feature that was added in 0.1.7 that requires Qt 4.2. I’m not very familiar with Gentoo but according to http://packages.gentoo.org/search/?sstring=qt Qt 4.2 should be available in testing.
Thanks for your help 🙂 I upgraded to Qt 4.2.1 using the “~x86” flag but I also had to reinstall dBus without Qt4 bindings, now nzb compiled clean and works great, thx for the SSL support 🙂 Haven’t a clue what dBus is but nzb works without it no problem. Keep up the good work, your program is great 😀
First of all thnx for making this great program !!!
In order to help you test, I found out that on winxp pro sp2 running version 0.1.7 unchecking the checkboxes before or while downloading makes the program crash. Besides that it does everything I need in basic and that is just fantastic…
Small feature request…
Since you display download speed and total download size en percentage of downloaded mb versus total size, could you add remaining time?
Thnx in advance!!!
Sorry small add-on,
It does not crash the second you uncheck the box but when the program arrives at the unchecked box it will..
Hmm, I can’t seem to reproduce the problem. Do you have an .nzb file that this happens with that I could try? Does this happen for every nzb file? This bug should have been fixed as of 0.1.5 but this might be another issue.
buggy as hell. Crashes at the slightest thing. Wont play back 99% of nzb files… no help. :(:(
Interesting. Where do you get the .nzb files from? Do you have a sample that doesn’t work that I could try?
I’ve been using this program since 0.1.6, and now i have 0.1.7 . I still seem to be having difficulties with the program crashing after hours of usage downloading. The most frustrating part is the failure of the decoder to compile the files already downloaded. This regrettably means that i have to re-download all the files all over again that were not compiled by the decoder. I also find it frustrating that all the news posts are not stored in a temp folder as they are downloaded, this would be useful if the decoder fails to initiate.
Id love to see this bug fixed, apart from that amazing program!
Every time I try and download a large amount of data, say about 4Gig, I usually get this:
Error: “503 Backend Error. No. 0x69000129”
then the program will crash out a bit later. Any ideas what could be the cause?
Using 0.1.7 version on Xubuntu 6.10 and Gentoo 2006.1.
A way to queue, pause and resume downloads would be cool, please.
That error is sent from your Usenet provider, an issue on their side. nzb should however of course handle it gracefully and continue.
I noticed that the app appears to decode everything into memory without writing temporary files to the HDD. In return, this ends up with the program using a pretty big memory footprint while it’s downloading and decoding data. Any chance for the next release you could make it cache data to the download folder? I know that the OS will page out memory to disk, but right now nzb.exe is using 720mb of RAM, and that’s affecting the speed other programs on my machine run at.
It doesn’t save downloaded parts on disk, however, after decoding the part it writes to disk and removes the stored part from memory. Usually when downloading it shouldn’t use more than a few megs for downloaded data.
If you are streaming a file it stores the decoded data in memory until the application reading the stream has read that data, which in certain cases can cause quite high memory usage.
Are you streaming or downloading, and what OS are you running?
I’ve also experienced those (minor though, compared to other nzb-capable grabbers) troubles with nzb, and I second xempt in his wish to have downloaded parts cached on the disk to prevent one from re-fetching articles after a hang.
I’d also be very happy if nzb was able to re-connect timed out or broken connections, both after a failure in the nntp host or after a forced dialup reconnect, because those make the program abort its download on my system (XP pc behind dsl router).
Otherwise, thanks for a nice piece of software 🙂
What a piece of garbage. Don’t use this. If you accidentally click the play button instead of start, it downloads the entire video into memory and doesn’t save anything anywhere. If VLC doesn’t like it, your hooped. Have to re-download all over again.