fillserver option not supported ?

As a workaround I created a "hellanzb_simplified.conf" file without the fillserver option and declared this file in lottanzb.
-> working in mode "local platform"

Hi Jacques,

thanks for reporting this issue. The reason why this option isn't supported yet is simple: We didn't even know of its existence and LottaNZB is a little too restrictive regarding unknown options. I spotted the expression "fillserver" several times while looking through the HellaNZB source code but as it seems, this "fillserver" option is poorly documented. Could you give us an explanation what this option does exactly?

We'll ensure that the fillserver option won't cause errors anymore in future versions of LottaNZB.

For the moment, I can point you out to a (probably) more elegant workaround: Select the "Remote front-end mode" and just enter "localhost" plus the port and password specified in you original HellaNZB configuration file (launch HellaNZB using this one). In this mode, LottaNZB doesn't parse any configuration files.

Hello,

fillserver option is usefull to declare secondary server(s) to only be used if the content to download is not present on the primary (nonfill) server(s).
It is usefull for example if you a have a short retention unlimited account and a longer retention limited one.

nonfill server(s) : fillserver = 0 (default option value)
fill server(s) : fillserver > 0, servers with fillserver = 1 being used before fillserver = 2, etc...

I will try your workaround later, seems indeed more elegant :p

Cheers.

Thanks for your helpful explanation.

If created both a bug report, which aims to prevent LottaNZB from crashing like in your case and a blueprint (https://blueprints.launchpad.net/lottanzb/+spec/fillserver-option-support). LottaNZB should provide a convenient and unobtrusive way of setting the fillserver value.

Hello,

Your solutions works, but you loose the link to the 'done' folder in this mode, so I will stick with mine for now :p

Cheers.

Fill server support would be great. In fact, back when my ISP's free NNTP service sucked, I would have considered it essential and would not even consider using a product that didn't support it, free or not. My ISP has since outsourced their NNTP service to GigaNews, so this is not really a great concern for me anymore, but it still would be nice. I'm surprised that more people are not requesting it, though, since most ISP services are really bad (or has that changed???). It allows you to save a lot of money if you need a premium server, by opting for a pay as you go plan such as (http://www.news.astraweb.com/downloadplans.html) rather than a monthly fee plan and only using the premium server as needed. Depending on the quality of your free service, that may not be much at all.

See also:
http://www.hellanzb.com/trac/hellanzb/ticket/36

The good news is that since LottaNZB 0.4, the application doesn't crash anymore if the fillserver property is specified in the configuration file, but it's still not possible to change the value from within LottaNZB. What you have to do is to manually edit the ~/.lottanzb/lottanzb.conf file (or ~/.config/lottanzb/lottanzb.conf in LottaNZB 0.5). I might think about adding it to LottaNZB 0.5 (as a last-minute feature) or LottaNZB 0.5.1 though.

If you have a look at the blueprint (https://blueprints.edge.launchpad.net/lottanzb/+spec/fillserver-option-support) you can see that we're still not sure what the best implementation from a UI point of view would look like. Would it be necessary to allow two or more servers to have the same fillserver value (like 2 times 0 and one server with fillserver value of 1)? Or could we make the server list reordable, so that.the topmost server gets a fillserver value of 0, the one below it 1, etc.? This would be the least invasive change. The alternative would be (yet) another entry box in the server dialog.

I look forward to hear from you what you think about this!

Although either would work for my purposes, I would imagine that to be complete you would want to allow multiple servers to have the same value. Consider this example:

You have two unlimited servers that you always want to download from first. You will also want to download from these servers simultaneously to maximize your bandwidth. You have two free servers that limit you to 50 MB per day that you would like to use as the primary fill servers. You have one pay-per-use premium server that you want to use as a last resort.

0 - Unlimited #1
0 - Unlimited #2
____ 1 - Limited #1
____ 1 - Limited #2
________ 2 - Premium Server

The best and easiest option (in my opinion) would just be to have another option on the edit server screen that looks like the maximum number of connections option which would allow you to manually set the server priority. This would, of course, default to 0.

Thanks for your response. I see that one should allow users to set up such a configuration even if it won't be relevant to most users.

But even if such an option existed, it should not confuse users in any way. Just adding a simple "Fillserver: [.......]" field won't do the trick, as most users won't know what a value of 0 or 1 etc means without a (one-line) explanation below that.

So here is what I suggest to do:

Make the server dialog depend on the number of servers that have already been specified.

- If the user is adding the first server or editing the only existing server, don't display anything related to the fillserver option.
- If the user is adding a second server or editing one of two existing servers, display a checkbox that let's the user specify if the server should be a fillserver or not. Don't let the user mark both server as fillservers (somehow ;-)).
- If the user is adding a third, fourth, etc. server or editing one of three or more servers, display a spin button (like the connection option) with a one-line explanation below that that 0 is the highest priority etc.

Users who only use one server won't be affected by the change at all.

You're right. Your suggestion does sound more intuitive (although it also sounds like a lot more work). I was originally thinking you were talking about basing the server priority solely on the order of the servers, and I could see that causing many problems. I like this idea, though.

Yeah, solely basing the server priority on the server order would be intuitive, but rather limiting in terms of configurability.

Changing the server dialog according to what I wrote in the previous post, is definitively more work, but when it comes to usability, everything is worth the effort. :-)

Since this change would introduce new strings (for translation) and also affect quite some code, I'll postpone the implementation of this blueprint to 0.5.1, to be released soon after 0.5.

Thanks for your input and stay tuned.