No such article

[Zefbot]

Ah, thank you for pointing that our Jesus.  I had the problem again last night and when I checked the log any errors were T8.  I went back to the other night's log when I first had major dramas and it was T9 that caused me woes. 

So other than contacting UNS, which I will, I've put the retry timing on 5mins.  I assume what I am hoping for is connection to a different front end when it reconnects?

EDIT: I just contacted UNS via their live support chat and they couldn't offer any solution but said they would bring the issue to the attention of engineering.  They did get me to connect to their server via telnet to see which fe I connected to (it shows in the welcome message) but I'm not sure what that proved as I tried it again a few minutes later and connected to a different fe.  It's always going to be different isn't it? 

[Jesus]

When you connect, it's almost always going to be a different fe.  If alt.binz doesn't show the welcome message in its logs, then some other program that does would be better for reporting frontend problems to UNS, and telling you which fe(s) to avoid.  But look at the DNS for the SSL server:

Hostname: secure.usenetserver.com
IP Address: 208.49.82.92
IP Address: 208.49.82.185
IP Address: 208.49.82.218

The .92 address connects you to low-numbered fe's, and the other two connect you to high numbered fe's.  If you discovered that a low-numbered fe was giving you a lot of 430's, you might be able to avoid that by using one or both of the other two IP addresses, instead of using 'secure.usenetserver.com'.  One IP address could be used as primary, and another as a fill server.

[Zefbot]

Thanks again Jesus.  Unfortunately it doesn't seem the fe is mentioned in the log file so I have no idea what fe I am connecting to when I have issues. 

Does anyone know of a program that would save this information?

[Jesus]

I only know of some of the programs that will log more of the NNTP session details than alt.binz does.

NewsLeecher, with "extreme debugging" log enabled I think.

Newsbin Pro, if you change a registry setting for that program.

SABnzbd's logging shows the connect welcome messages and the thread number.

Forte Agent, with verbose logging enabled.

Probably many other programs, which I don't know about their debug logging capabilities.

[Contra]

Thanks for all your help Jesus. For the record, I was connecting to 208.49.82.92 when the log I posted above was created.

For now, I've just set retries to 100 with a 5 minute delay and I haven't had any more problems.   

[cr4zyfr4g]

Thanks for all your help Jesus. For the record, I was connecting to 208.49.82.92 when the log I posted above was created.

For now, I've just set retries to 100 with a 5 minute delay and I haven't had any more problems.   

but be aware if a part is realy missing you would have to wait ~500 minutes until it would be completetd, checked and unrared

[Contra]

True, but if I saw that it was genuinely missing I could deal with it manually.

[Jesus]

Because .92 only connects to low-numbered frontends, and you had that trouble, I would avoid .92 completely for now, and instead configure .185 as priority and .218 as a fill server backup.  On a 430 you don't want alt.binz to try the same 'fe' 5 minutes later or the same fe every 5 minutes, you want it to immediately try a different fe.

[Contra]

On a 430 you don't want alt.binz to try the same 'fe' 5 minutes later or the same fe every 5 minutes, you want it to immediately try a different fe.

I realized this, of course, but I hadn't noticed that it was possible to configure a backup server for that purpose (although I see now that it's the obvious solution). Thanks for the advice, once again! 

[Hecks]

Because .92 only connects to low-numbered frontends, and you had that trouble, I would avoid .92 completely for now, and instead configure .185 as priority and .218 as a fill server backup.  On a 430 you don't want alt.binz to try the same 'fe' 5 minutes later or the same fe every 5 minutes, you want it to immediately try a different fe.

This is assuming that the fe is failing completely, and not just being slow to retrieve the files.  Such behaviour is common enough with some servers - it's one of the reasons why the delay before retry setting exists.  Anyway, no doubt Contra will hear more from his provider in due course.