(Not Necessarily a Bug) Issue with No. of Connections in 0.48.2.2

[Master_Raver99]

I found an issue with my number of connections set to 100 with Usenet Server Global SSL server causes the application to hang and require end task.

The file downloading was 227 GB in size and when I set it to download over night it managed to reach 147 GB before I noticed the program bad become unresponsive. I attempted the the download again and the program once again stalled after 2GB had downloaded.

I have just recently updated to 0.48.2.2 from 0.47.4.1 and as to why my connections were set to 100 is due to recent instability with Usenet and the connections were raised from 20 to 100 to achieve full download speed on a 100MB uplink. Previously version 0.47.4.1 had no issues with 100 connections to the server.

Reducing my connections back to 20 has solved the issue on my end.

I just thought I would bring this to your attention and let me know if you have any questions.

[Rdl]

Few things:

no detailed log?
There are A LOT of changes between 0.47.4 and latest version. Did you try 0.48.1 or 0.48.0. They are still available for download.
100MB uplink? What is download speed? Are we talking 100MBit/s? What is your latency to server? I doubt you need 100 (even 20 is way too much) for 100 MBits connection.
Did you try non ssl under same conditions? Smaller downloads with 100 connections?

[Master_Raver99]

I apologise in advance as this is the first time poking around in the log file so my level of understanding is quite minimal.
I just checked the log for that day (45mb damn) and I can see Alt.Binz connect to my primary then switch to my secondary briefly to check the article in queue for some unknown reason.
I can see that all articles are starting and finishing as normal up until the point where I end task Alt.Binz.
So although Alt.Binz was operating as normal, the program appeared unresponsive to Windows 10 22H2.
My usual download speed peaks at 13mb/s and no, I hadn't tried 0.48.1 or 0.48.0 as I am a very basic user and tend to browse via the websites and manually download the nzb files.
My latency is 265ms (TTL:46) to news.usenetserver.com, 258ms (TTL:46) to news-us.usenetserver.com however, I cant seem to get a response from my backup server news.tweak-news.eu
I did also try non SSL under the same conditions and Alt.Binz again became unresponsive after a short period of time.
I have just played with the maximum number of connections again and lowering this back to 10 connections on SSL drops my download speed to 9mb/s. I then raised to 20 connections and I am back downloading at 13mb/s.
I can appreciate that Usenet Server plays as a major variable in all this due to server issues in the past, hence why I have to alter the number of connections from time to time.
I have just now tested a 4mb, 140mb and 1.3gb article with 100 connections to the SSL server and everything downloads fine at a healthy 13mb/s.
For testing purposes I have started to re-download the article which caused the above issue. As noted above, the previous article was 220gb, however when I successfully downloaded previously this it extracted to a mere 80gb and I note, the article was downloaded successfully.
I am now at 67gb left to download of the article and seeing Alt.Binz GUI occasionally turn all black with fluctuating download speeds at times. Memory usage also fluctuates between 400mb and 800mb.
Conclusion: It is quite possible there was issues with the article in which have been rectified, however 100 connections does appear to cause problems with my uplink speed on larger articles.
Let me know if you have any further questions and hope the above said helps.

[Rdl]

What is your article cache size set to? What is article size of 227GB download?

Could it be that normal altbinz mem usage + article cache size + 100 connections x article size is over 2GB process limit?

[Master_Raver99]

My cache size is set to 1000mb and the article size is 9479kb.

My "Remove articles stored in cache for then" is set to 30 minutes.

I probably should have elaborated more on the 227gb article. Originally this was a 227gb article when initially downloaded, however when I re-downloaded the article yesterday it's size was corrected to 80gb including par files and extracts to a 70gb iso.

Whilst downloading the article a couple of days ago, there may have been live corrections happening on the server causing part of the problem. This statement could also be supported by the mass amount of obfuscated files left over in the folder after the download completed.

As demonstrated yesterday, there were still some minor issues with Alt.Binz whilst downloading the 80gb article and connections set to 100.