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.
15 Mar 25: It looks like the search service is currently down as there are no pings. The other server is no more on starlink, but the search requests are still routed and the access to it is through the first server, since it is safer, but the direct access is no problem if this will be a repeated issue. The connection will be restored or server restarted as soon as possible.
16 Mar 25: One server is currently still down, the other server was reconfigured and already connected directly, so the search service is running with minimum possible retention gaps.
a server computer went down. exact reason i don't know yet, there appears to be connectivity in general (maybe not cannot tell for sure yet), but few days ago i noticed connectivity was shortly lost on that connection.
i accidentally forgot to switch on the search service monitor after the last database backup few days ago (switched it off during backup to avoid alarm sound, was night time), so there was no alarm when the problem started. in addition transformer burned around so there was outage during the day hours and i didn't check the forum, but if the search service monitor were on, i would be notified in time before the power went down.
i've switched to 150 day backup configuration, until i have the server computer up again.
the computer which went down is up again, i'm restarting the service with regular retention now.
the reason was winxp stuck in reboot with choose single hardware profile choice (such error is only documented by microsoft only for win2k).
i've restarted the computer to ensure it reboots ok, no error.
my speculation is there was some problem with power supply (some fluke in the voltage) which caused reboot and persisted while the computer was rebooting.
it has restarted already, just took a while, reboot then restart, all works.
i needed to check the reboot condition, apparently it is some kind of undocumented microsoft bug, they documented it for win2k but didn't really fix it.