How to handle servers with mixed retention

[Zeph]

I have a common situation: fast server with limited retention, slow server with longer retention.

With another newsreader I was used to choosing a server when loading an NZB; for older posts I would choose the slower server; for newer ones I'd choose the faster.  I can often know for certain that a given NZB is going to be completely beyond retention for the faster server.  I like to reserve the slower server for just older posts; it's a waste of its quota to fetch articles on the faster server.

Sometimes rather than age it's a matter of available newsgroups - the faster server has fewer so sometimes I know in advance that a given NZB has to be fetched from the slower server.

Alt.binz doesn't appear to have a way to associate a given nzb with a given (primary) server, right?

From reading here, I think the alt.binz approach would be to put the faster server as primary and the slower (longer retention) server as secondary to that.  NZBs for older postings just have to try and fail to find every single article on the faster server before retrying the slower one, right?  Does that slow things down much?

Or am I missing some feature or approach?

Thanks, Zeph

[Hecks]

With another newsreader I was used to choosing a server when loading an NZB; for older posts I would choose the slower server; for newer ones I'd choose the faster.

Which newsreader, out of curiosity?

[Zeph]

The newsreader which allowed me to choose a server when loading an NZB file was Grabit.

Alt.Binz appears to have a number of advantages over Grabit, tho I'm not yet as familiar with the former.  I'm looking for Alt.Binz tips to address some of what I miss from Grabit, after which I may fully switch over (and contribute, as I did for Grabit).  I'm just trying out Alt.Binz for now, to get a feel for what it can and cannot do.

Besides the approach I mentioned above (for older posts or missing newsgroups, just let Alt.Binz try every article on the faster server which won't have it before falling back to the slower server), if one wants download ONLY from the faster or the slower server, one could open only threads for that one.  My problem is that I want some nzbs to download slowly from the more comprehensive news server (using 40% of my ISP's bandwidth) while others download from the faster server (using the other 60%).

It would be great if a given download could optionally be associated with a given primary server (plus fallback secondaries).  This would be a feature like optionally selecting a per download folder.  Only threads for that primary server (and secondaries) would respond to that download.  If none was specified, then any thread might try to service the download as now.

Zeph

[Hecks]

What you're looking for can I think only be approximated by running more than one instance of Alt.Binz (using the -mi commandline switch) with different server settings and limiting speeds on each instance to those percentages, then (or so I guess from your description) queueing NZBs in one or the other depending on your server requirements.

Those are very specific requirements, though, and these days users generally need to do less of this kind of fiddling.  With Astraweb at just $11/month for unlimited and uncapped with retention growing to 365 days, it just isn't worth the hassle of managing multiple servers ... IMHO.

For the rest, Contributors can post feature requests in the Requests forum.

[Zeph]

Thanks, I'll try the multiple servers approach and see how that works.  That's exactly the kind of hint I needed - something that can be found once you know a relevant feature exists, but is hard to figure out using searches because you don't know the right keywords to look for.  "A human with domain specific knowledge can often immediately describe options which would not emerge even from hours of diligent searching".

I do hear your point about avoiding such hassle by skipping the free (ISP provided) news servers and just subscribing to one high bandwidth + long retention + broad selection commercial server.

Thanks again!