Virus and the other usual protections are all in place. It's also a new server but exhibiting the same symptoms as the old one. It is indeed a bug in the software itself. This can be demonstrated by navigating to a static webpage with no server-side scripting, for example the 'about us' page - https://vintage-radio.com.au/files/about-vintage-radio.html which will still work even when it's host site has clagged.

This is why I am coming to the conclusion that continuing with the current content management system is just a waste of time. The problem I have is that writing a new one is going to take even more time because I am out of practice. I am also considering starting afresh with a new database and having everything brand new and merely running the old content in an archived mode - we and search engines can read content but not continue to comment on it.

This may or may not be pertinent, but I notice that I don't usually have any connection issues when the "People here now" count is low, say below 50.

Update: something odd is occurring with that count. When I posted this message it said the count was 22, then I got a 500 type timeout and when I managed to get back on a few minutes later the count said 54.

I find it hard to believe that 30 more people logged on in the space of a few minutes.

Does that count include web crawlers?

I've made a study of that scenario in the past but have never been able to make a connection. Sometimes I've reached the 500 error at about 03:00 in the morning and the concurrent user count has been between 1 and 10. I'd be easy enough to block the IP addresses of the crawlers that don't matter to this site (and there's lots of them these days) but I haven't gone down this road because at the same time the user count has been in the order of hundreds and worked perfectly.

To clarify, the session manager does not include any non-humans in the unique visitor register, which is the number in the order of 6+ million. The default length of time for a session on a web server is 20 minutes. This can be changed but server administrators usually don't bother with it. If you visit the site, you register one 'hit' (this word is a misnomer, and I'll explain why in a tick). If your connection becomes idle then your session will expire in 20 minutes. Becoming idle simply means that you do not do anything further on the site in that 20 minute timeframe. If you visit further pages on the site within the timeframe you do not register another 'hit'. If your session does expire and then following that, you do visit further pages then you'll register another 'hit'.

The visitor counter operates this way in order for a webmaster to be prevented from saying, "look at the tens of millions of hits my site has!", because a 'hit' defines the download of the web page you visit plus every other piece of content on it, images, sound files, videos, the lot. On the main page of this website you'd register 5 or 6 hits just by visiting that page because there's several image files linked from there.

I've never filtered the concurrent user counter, however. It's more for my benefit as I want to see what the actual load is on the server. It's definitely feasible for there to be lots of humans here but I'd agree that it is unusual for them to all arrive in the space of a few minutes. This can be cross-referenced with the site's logging system to find out whether a connection is a person or a robot. One set of logs records events, such as when members sign on and off, whether they sign on manually or have used the 'remember me' function, change details in their profiles or use the password retrieval service. If a member has their account stolen or is having trouble logging in or retrieving their password I can usually find out the hows and whys by looking at this log file. The other log records anyone or anything that visits the website and records the time, date, operating system and browser versions, IP address, hostname (if any), language settings and referring URL (if any). From this log, I can determine if anyone is visiting too frequently - meaning an attack on the site designed to flood the connection.

Because Internet connections are full duplex these days the presence of web crawlers (or me watching video content on the same connection) is not a contributing factor to server errors. Once your browser's GET request hits the server it should reply instantly as the reverse data path is not congested. I once hosted celebrity chats on an IRC server here with more than 400 concurrent users and these also occurred with no congestion and the numerous websites hosted at the same time, including VR, also operated normally.

With the site software now in its 14th year, I can concur with something said by Ian - sometimes it is hard to spot one's own mistakes. It took me a long time to spot the one I found but there's obviously at least one more. Tomorrow morning I will be doing some minor work on the site to check on a few other things that have come to mind. The same will occur the following Sunday, if I can allocate the time for it. If there's no improvement I will build a new CMS early in the new year.

I am not sure of what to do in the interim though. I know the errors are extremely annoying. But at the same time I don't see any benefit in closing the forums down and driving everyone away literally for months.

I'm surprised to see posts from yesterday, as I could not connect for the entire day.

I could not connect for the entire day.

Out of interest, which ISP are you with?

The ISP won't be an issue. I have Telstra, Optus and Vodafone SIM cards here (long story as to why) plus TPG for my landline and all either work or don't work simultaneously when attempting to access this site. If anyone is contemplating a change of ISP to try and improve their access chances, don't waste your money or time. It won't work. When things are fine here your current ISP will be fine. When you have trouble connecting, it is not your ISP's fault.

I wish I could bring better news on that front.

The reason I asked is that sometimes I cannot connect to a site via my regular ISP, but can do so via another one.

Meanwhile, almost as soon as I posted that question I was back in limbo. I'm now wondering it it takes a posting action to trigger a 500, rather than just viewing posts.

A better test is to revert to the first connection as soon as you get goodness on the second, then if the first is still playing up, try the second again. On the first connection, don't just refresh, close the browser and restart.

Due to the increasing frequency of server errors, I am going to temporarily close the site between Sunday, 5th November at 08:00 (GMT + 11) and reopen on Sunday, 12th November at 08:00 (GMT + 11). For the first few days of this period, the site will not be available at all. Following this, the site will be gradually re-enabled but there will be no access to the forums until the 12th, assuming I can find what is causing the problem. My main priority at this stage is to return Vintage Radio to a state of complete stability. I do not think it is pertinent to wait until 2018 to do this work and the plan is to be back to normal before Christmas.

At various times, members will see the test card holding page and older versions of the site, including the old narrow site, but again, access to the forums will not be available between the 5th and 12th November.

Hopefully during this period I can find the cause and wipe it out once and for all.

Good idea, and best of luck with the bug hunt.

Some of this may help: https://wholefully.com/wp-content/uploads/2014/05/IMG_3740.jpg

At the risk of calling up the Devil, this site seems to be performing okay again today after a shocker yesterday,.

I note that those visitor counts are zero, so perhaps they do contribute to the problem after all?

Yeah it might be coincidence, but the really bad part appeared to start when the people counter was fixed.

Turns out I did call up the Devil last night following post #191. It does seem to be (also?) related to making posts.

I've set the counters to nought on the page itself but not for that reason. When the site times out the counters go out of sync and were returning false readings. There's no long term issue with this as the counters are recording the correct results and will be back whenever the site is behaving again.

There's a duplicate thread in the Wanted section, however clicking on it gives an instant Error 500.

This one errors - https://vintage-radio.com.au/default.asp?f=3&th=1072

and this one works - https://vintage-radio.com.au/default.asp?f=3&th=1071

Some sort of database corruption?