Retry count not working the same in 0.47.1.1 as it did in Free Version

[sidbib]

Hello,
   I used the free version (0.39.4) for a long time and got very comfortable with how retry count worked. For a while on Frugal Usenet, I found that articles that reported as missing would successfully download if you retried them multiple times. So instead of setting up a backup usenet server, I set retry count to a high number and delay between retries to 0. When a missing article was found, Alt.Binz would continue to retry that article until either it downloaded or the retry count was hit - at which point it would mark the file red (incomplete) and move on. Once all articles were either skipped or downloaded, decoding of the file would take place. I could set the retry count to 999 and Alt.Binz would retry the missing articles basically forever

I watch all of my downloads as they happen, so using 999 would show me a problem with the post and I could decide to lower the retry count and let it decode incomplete files, or I could pause the download and switch to a different server before continuing.

I am using the same settings now on 0.47.1.1 but when retry count is set to 999 it retries broken articles multiple times and then just gives up, moves along to the next file, and leaves the broken file partially downloaded without decoding.

I'm not sure if this is a bug or If I need to do something differently in the new version to replicate what worked in the free version.

Thanks for any advice.

[Rdl]

I've tested this and could not reproduce. Setting 999 retry count with 0 delay is not 'forever'. Here it goes through them in 17 minutes (1 retry every 1 second)

[sidbib]

I used a smiley face after "basically forever" since I would never let it retry the same broken articles for 17 minutes without intervening (as I said, I watch all my downloads live).

I am using 0.47.1.1 as portable - I dropped the exe into the same folder where portable 0.39.4 was already working. Could this be related? I am also on Windows 7.

A bit more information: With the 999 setting, after it gave up trying and left the partially downloaded rars in queue instead of decoding them, sometimes I could disconnect then reconnect my server and it would try some more. But other times I had to shut down and re-launch altbinz before it would try again. I began trying just 1 broken rar at a time, and when I could get it to try again - it would try a random number of times and then stop trying again. When I counted the number of article not found messages in the log tab, it would be low numbers like 21, 30, etc.

[Rdl]

Send me via PM links to following:
-screenshot of the download queue of the problematic nzb (make sure age is visible)
-screenshot of the setup/servers
-screenshot of the setup/connection
-detailed log of the problematic nzb download

[sidbib]

I was in the process of creating the screenshots you requested when I made a new discovery.

I typically have three "Level 0" servers active all at once. One paid server and two free servers. I use 12 connections, 10 to the paid server and then 1 each to the two free servers. The free servers have limited retention, so when I download something older I always right-click the two free server threads in the connection panel and select "Disable thread".

The nzb I was using to document this issue is older than the retention of the free servers, so in order to make a cleaner screenshot - I unselected the two free servers (from Setup > Servers Option) and only had the paid server active.
And then I found that when I only have the one active server (10 connections), the retry count works correctly.

So, I added back in the two free servers (1 connection each), disabled the free server threads, and sure enough - the retry stops working.
And once it goes through and gives up on all the the broken rars and quits trying (with partially downloaded rars just sitting in the queue) - If I enable the disabled download threads, it goes back to working properly & eventually decodes the partial rars. This is certainly not how it worked in 0.39.4. Disabling the other server threads didn't make any difference in that version.

I can still make the screenshots if you like, but with this new info are they still needed?

[cornel.mc]

have a look at NZBGet. Runs much better. Alt.Binz is showing isuees lately...the most annoying is queues not cleaning on shutdown and keep trying to downloading the same thing...sad

[Rdl]

I was in the process of creating the screenshots you requested when I made a new discovery.

I typically have three "Level 0" servers active all at once. One paid server and two free servers. I use 12 connections, 10 to the paid server and then 1 each to the two free servers. The free servers have limited retention, so when I download something older I always right-click the two free server threads in the connection panel and select "Disable thread".

The nzb I was using to document this issue is older than the retention of the free servers, so in order to make a cleaner screenshot - I unselected the two free servers (from Setup > Servers Option) and only had the paid server active.
And then I found that when I only have the one active server (10 connections), the retry count works correctly.

So, I added back in the two free servers (1 connection each), disabled the free server threads, and sure enough - the retry stops working.
And once it goes through and gives up on all the the broken rars and quits trying (with partially downloaded rars just sitting in the queue) - If I enable the disabled download threads, it goes back to working properly & eventually decodes the partial rars. This is certainly not how it worked in 0.39.4. Disabling the other server threads didn't make any difference in that version.

I can still make the screenshots if you like, but with this new info are they still needed?

When you change servers -> right click on collection in queue and click reset.

[Rdl]

have a look at NZBGet. Runs much better. Alt.Binz is showing isuees lately...the most annoying is queues not cleaning on shutdown and keep trying to downloading the same thing...sad

Yuo couldn't report those issues?

[sidbib]

When you change servers -> right click on collection in queue and click reset.

Thanks. I tried the reset as you suggested. When I click reset, it does go back to the top of the queue and try again on rar files it had previously stopped trying on and moved past. However, it quickly gives up on them again and I end up right back in the same scenario. Each time I selected reset it would try again for a short period but still gives up and moves on. And I had my retry count set to a low value of 5.

Is there something else you would like to me try?

[Rdl]

We should arrange teamviewer session so I could see what is going on.

[sidbib]

While I am not opposed to that, I have never seen or used teamviewer - nor do I have it installed.