Support Forum

Thanks Shypike! I appreciate your help & support!

I took my last patch and updated it again the current trunk build (3388). Here's another attempt: http://pastebin.com/raw.php?i=ZWNVKnVZ By watching the logs, I'm fairly certain that this is actually killing the thread and starting a new one after the configured byte limit is reached. Unfortunately,...

In response to the hesitation over the ISP variance; I offered in reply #5 that the issue could be mediated with a user modifiable option for either time or byte limits. Given the vast majority of users would hit byte limits far before any arbitrary time threshold, I'd vote for the byte limit myself...

Here's another patch that actually cycles each thread as they cap out: http://pastebin.com/f3a7a7aa1 Unfortunately, it isn't any faster though. I think we may need to look at the actual TCP socket call for "__reset_nw" and make sure it actually closes the socket and opens a new socket. Any...

Yeah, I never reported the speed, but it wasn't any faster, sadly. I did try stepping through the connections with a delay between them. However, as this is my first attempt with Python, I wasn't calling it right and it just bombs out. I'll be off again next week through the end of the year, I think...

It took me a while to get some free time, but I wrote a quick and dirty patch: http://pastebin.com/m4c9834b5 This was patched against the current SVN 3079 and I wrote the Plush code and English configuration settings. Fundamentally it works as expected. After X number of kilobytes SABnzbd+ does a fo...

I hate to disappoint you, but it isn't high on our todo list. We already have a large backlog of other requests that have a larger potential audience. We do welcome working patches  :D So, just to verify my understanding. If I write a patch for you that does this feature request, you'll incorporate...

First off, I can see your point of view and I honestly appreciate your offering for a solution that may fit this feature request. It is sincerely appreciated and I hope that it can be incorporated effectively. However, I would like to offer some correct to a couple points that have been made: Settin...

This insinuation of abuse and the theory of "sticking it to the ISP" is only as valid as the reasoning behind allowing a user to change their NNTP server port setting! Seriously, why allow users to change this port setting? Maybe to bypass certain ISP limitations, per chance? Wouldn't this...

I don't consider it as F'ing Comcast. To the contrary, I would consider it a utilizing a feature that my ISP offers for a service that I pay well for. To call it F'ing Comast it analogous to say that if I were to use the 2GB a month they give us on Giganews as also F'ing them. Or if I used the Antiv...

I can verify and assure that they start about 1500KBps and drop to 750KBps. It does this with every download I do. This is consistent regardless if it is usenet, HTTP, FTP, etc. Specifically, I configure sabnzbd to disconnect when checking and unpacking the NZB. When it reconnects it jumps to 1500KB...

First off, thanks for the quick response! In all reality, the feature that we would be looking for is an option to drop active server threads after a static byte limit that the user could set. Sort of like your speed limit option, for example. Theoretically, a) I assume that there is a significant a...

I would like to second this feature request. If we could have an option to cycle the connections after X Bytes/Seconds, it would really helps us *take advantage* of the powerboost feature!  ;) Comcast also has a FAQ about SpeedBoost here: http://www.comcast.com/Customers/FAQ/FaqCategory.ashx?CatId=3...