03 Oct 23: One server has been relocated, the server currently doesn't have a public IP address in the meantime. I wrote some additional tunnel code running separately to handle this. When the server is engaged the connection is 5600+ days uniform (since around 24 July 2008). In the unlikely case I disengaged the server because of some problem the retention is 1200-3800 days depending on newsgroup. If you experience any issue please let me know.
29 Nov 23: Because of encrypted and "obfuscated" flood mass posted by few nzb websites and newzbin-like communities using usenet servers as private storage for their members to download the posts - the situation with the content is pretty chaotic, since posts are disguised in such a way, that users must use the satellite ecosystem (whish is not a part of Usenet) exclusively to download them, when the website disappears - the encrypted scattered posts just eat usenet providers' disk space uselessly. If you can't find something specific please let me know what exactly you can't find for me to check how it is possible to retain the posts. Legible posts shouldn't be affected at all, let me know if you notice anything missing.
08 Aug 24: After being unchanged for many years the search service communication protocol had to be updated a few times in part to resolve a server side set feature limitation and properly handle trial searches on the relocated server. The searches themselves are not affected and it looks like the work is now complete.
yes, i know, those messages are shown here in the server control panel, this is not a problem with server workings.
i need to add a simple modification to avoid those messages, i sorted out other things here, i'll do it shortly and get here back when it has been done.
i added a little code and restarted the server with the changes, but the problem didn't happen for two weeks or so, when it does (or when there are signs without this actually happening) then i can take effective measures to prevent it from reoccuring.
no problem with the server itself, in short it is a kind of inadvertent user abuse.
based on my observations the problem has been taken care of as to prior external causes, i'll add more refined code later as a matter of precaution, need a client release since need to return new error message in a certain case to prevent such an issue.
i did some more work on the topic as i planned, while i'm writing this - the server is being restarted with more changes, i have now much better understanding of how to deal with the issue at the root.
