Since we are in an era where even a misplaced comma in a thread title requires remediation, I believe the time is ripe to get to the bottom of an operational mystery that has puzzled me for some time.

Replies that are successfully placed inline within a thread's body, yet fail to show the most recent contributors name on the "last post" column of heading page?

For example, in the "I believe the children are our future" thread, I posted a reply after Biff Bronson's entry.... and while my post recorded properly, Biff Bronson's (earlier) post is still listed as the most recent.

I found this confusing because at first I suspected Biff might have responded to my post, only to discover some hiccup must have obliterated my entry in the "last post" column.

Frustrating and confusing well beyond a misplaced comma, and has been happening for a while...... when can this malfunction at last be fixed? :)

Just to document the situation, I made the following screenshot at 9:39 this morning, still showing Biff's earlier reply as most recent, despite my having contributed at 8:57 am.

It's not just me you should be trying to please here. Think of all the people who can't wait to jump on one of my posts just to tell me how wrong I am. You can't deny these good people their moment!!

https://i.imgur.com/Vdr4HOw.png

I don't remember when I've last seen it happen like in that example. The problem is usually at the start of a new page of replies. Sometimes it doesn't generate a new page even though the post is in the database. It doesn't happen very often, so I'm not sure what could be causing it.

I just made a test post and deleted it. It now displays yours as the last post.

I would be more concerned if posts weren't making it into the database at all, which has happened a few times with new threads when I don't even receive the post sent to my e-mail.

I share your frustration. I would fix it if I knew what was causing the issue. There's no rhyme or reason as to when it happens. It could be just a temporary glitch when the server is especially busy or runs out of memory. The occasional hiccup is going to happen.

Maybe it has something to do with the cache. I have it set at 31 days. I've tried it at 0, 7 and 14 days. It doesn't seem to matter.

Cached Posts Lifespan
Number of days to maintain a cached copy of a post. This makes threads faster to display, but means that each post takes approximately twice the storage space.
31

Cached Posts Lifespan
Posts are normally stored with BB code tags etc. in the same form as the user posted them with so that it may be edited later, and then parsed at display time. By caching them, they are parsed at post time (instead of display time) into the HTML they will be displayed in and stored separately from the pre-parsed posts. This results in a faster display on threads, since the posts do not have to be parsed at display time.

This option determines how long posts are stored. While a post is cached, it will take approximately twice as much storage space since it is essentially being stored twice. If you have a busy site, and threads typically don't last very long, you can probably set this to a lower value such as 10 days. If you have a slower site, and threads typically last longer, 20 to 30 days might be a better choice. If you have the disc space, you can set this to a higher value for better performance.

-----------------------------------------------

Disc space isn't an issue. I can set it at any number of days.

Your indulgence is appreciated. The problem, as presented,I have experienced perhaps a half dozen times over the time I've been coming here, and can't remember it being related to the start of a new page, in any of my instances.
And yeah, whenever it has happened, anytime that I posted a follow up message, that seems to clear it up. So I doubt the problem is at my end...

There is a brain fart somewhere in the software...magnitudes of order more annoying than errant commas. :D

It's either a software or server issue. We're running older versions of MySQL (5.7.41-cll-lve) and PHP (5.6.40), so maybe that is a factor. It's not a browser specific issue.

A half dozen times over a 3-4 year period doesn't seem like a major issue to me. In a perfect world, it shouldn't happen at all.

**** happens sometimes. If there's a technical glitch at the time a post is made, it doesn't go back to automatically update and fix it.

There's many maintenance options. I could try running some of these during off hours. I wouldn't want to run any of these during peak hours because they might slow things down.

The search index definitely needs to be rebuilt at some point. There were many common words such as down and under which were omitted from the search index.

Update User Titles and Ranks
Number of Users to process per cycle
1000

Help Rebuild Thread Information
Number of threads to process per cycle
2000

Help Rebuild Forum Information
Number of forums to process per cycle
100

Help Fix broken user profiles
Finds any users who do not have complete entries in the database. Sometimes the data is not inserted correctly and the user's profile becomes unusable. Running this should correct any incomplete profiles.

Help Rebuild Search Index
Note: If you are re-indexing, you may want to empty the indexes. Click Here to do so!
Number of posts to process per cycle
250

Post ID to start at
0

Total number of posts to process:
(0 for unlimited)
0

Include automatic JavaScript redirect to next page?
Yes No

Note: This is a server intensive process.


Help Rebuild Post Cache
Number of posts to process per cycle
1000

Help Empty Signature Cache
If you have made changes that affect the output of signatures, you may use this to empty the cache and force signatures to be rebuilt with the new settings.

Help Rebuild Statistics
Rebuilding statistics will cause the loss of the total forum view and active users data. Only run this if you believe you really need to! Once the data has been replaced, there is no way to restore your database.

Help Rebuild Similar Threads
Note: This will rebuild the similar thread list regardless of whether they are enabled or not. However, they will not be displayed until the option is enabled.
Number of threads to process per cycle
100

Help Delete Duplicate Threads
Note: Duplicate threads are threads that have the same title, post name, and post time and are posting in the same forum as another thread.
Number of threads to process per cycle
500

Help Rebuild Attachment Thumbnails
This function rebuilds the attachment thumbnails. It is needed when you enable thumbnails, change the thumbnail dimensions, or change the thumbnail JPG quality.
Number of attachments to process per cycle
25

Thumbnail Quality
75

Include automatic JavaScript redirect to next page?
Yes No


Help Rebuild Custom Avatar Thumbnails
Number of avatars to process per cycle
25

Include automatic JavaScript redirect to next page?
Yes No

Help Rebuild Avatar Thumbnails
Number of avatars to process per cycle
25

Include automatic JavaScript redirect to next page?
Yes No

Help Rebuild Social Group Icon Thumbnails
Number of icons to process per cycle
25

Thumbnail Quality
75

Include automatic JavaScript redirect to next page?
Yes No

Help Rebuild Recently Updated Albums
This will recalculate the albums to display in the Recently Updated Albums list, effectively removing any albums that are no longer accessible. This may be the case if any users recently made album updates but have since had their album permissions revoked.

Help Rebuild User Reputation
This function recalculates user reputation using the value that you specify below then adds the total reputation the user has received so far. This will remove any custom reputation that has been given to the user through the user editor.
Base Reputation Value
10

Help Update User Names
Number of Users to process per cycle
1000

Help Update Post Counts
This will recalculate all of your user's post counts based on their CURRENT posts in the database. Do not run this if you have pruned posts, manually changed post counts, or imported from another forum package and you wish to maintain your users' current counts. Your members' post counts will PROBABLY decrease so only run this if you believe you really need to! Once they decrease you cannot bring them back up without restoring your database or manually editing each user. You have been warned!
Number of Users to process per cycle
1000

Help Rebuild Styles
This function allows you to completely rebuild all style information. This is necessary after a major upgrade, or if you have manually edited any of the 'special' templates.
Check For Styles With No Parent
Yes No

Renumber all templates from 1
Note: this option requires that your MySQL account has ALTER, CREATE and DROP privileges.
If you are not sure, do not use this option!
Yes No

Help Remove Orphan Threads
This function removes all threads that belong to forums that no longer exist.
Number of threads to process per cycle
50

Help Remove Orphan Posts
This function removes all posts that belong to threads that no longer exist.
Number of posts to process per cycle
50

I posted about this issue back in November 2020 and I haven’t really seen it happening all that much since then. I see now that it still is.

Well, the software NEVER seems to miss when we press "search" more than once in a 30 second time period.:D I'll give credit for it's diligence.

What amazes me about that is the way it will terminate a search already under way, just to give us the "doh-doh" award and force us to wait even longer before continuing.

Seems like it would be more productive (as well as less punitive) to simply disregard subsequent search requests once an initial one is already under way in that session.

LOL, perhaps the dysfunction at the heart of this thread is caused when the software is otherwise preoccupied policing search activity abuses? :crazy:

I've always found the concept of preemptive multitasking to be one of the more interesting aspects of computer operation. Perhaps this hiccup is the result of the software answering higher priorities, and failing to buffer what was preempted, while it attends those priorities?

The search is one of the most database intensive activities. It can slow things down more than anything else. I can try it at 15 or 20 seconds. I wish there was a separate search setting time for View Today's Active Threads/View New Posts and general searches. My concern is that bots are going to flood it with search requests. If it significantly slows things down, I'm going to have to raise it back to 30 seconds. There needs to be some breathing room between searches.

the really weird thing about searches is sometimes while the search is underway, the little "clock face" in the browser tab starts it's churn, and you can tell the search is in progress...everything is happy.

But, on occasion, you start the search and the little clockface either doesn't show up, or appears stationary.......suggesting to the user that something is broken., But you click again, and immediately get the "scoldy" screen telling us to be patient

So, from my perspective, the problem is not the 30 seconds. the problem is the lack of evidence that the requested search is in fact being performed, albeit covertly.

I guess what I am most surprised over is that your software responds immediately to the second "errant" request for a search, by shutting down the search already in progress, when simply ignoring any search requests made while a search is in progress would be more productive.

Perhaps, since the clockface in the browser tab is not 100% reliable, maybe a popup window displaying during the search, to confirm to the user that something is happening might be a solution. Feedback, in other words

For me anyway, that second click is really not intended as a "hurry up, already" type request.... It's more like a "why isn't anything happening?" affair (fwiw)

I'm late here, but the first post isn't a common problem--it's rare, IMO. Slightly more common is what TJ mentioned--a post which would appear on a new page is in the database, but the page does not appear. The easy solution to that is to make another post, which remedies the problem. "Slightly more common" is an apt description--it's relatively rare.

Even more rare is running into a problem with a search, at least for me.