I see. I guess the problem is the full text search on the msg column. OK please close.

You might want to know that, but it doubles the generation time of the page to show that information. We "cheat" when the execution time of the query is >0.5 seconds.

On my test install it increases the generation time of that page from 15 seconds to 30 seconds.

I can't reproduce the variable reset issue in current code, neither on the /syslog/ page nor the per-device syslog tab.

Apologies, the pagination bar makes it appear that way. So you are correct the term does not reset. But the pagination bar does not reflect the number of results returned.

The count being wrong is by design... This is because on large installs generating the count for a full text search will make the interface too slow to use.

I would argue that generating the count makes the search much more useful. I don't mind a performance hit to know the results of my search.

Eg. If my syslog was pushing firewall block messages to Observium, and I was searching for a suspect IP address I would want to know how many times they've been attempting to breach the firewall.

I can't reproduce the variable reset issue in current code, neither on the /syslog/ page nor the per-device syslog tab.

The count being wrong is by design, we abort the query that generates the count if it takes more than 500ms and just use the total table count as a placeholder. This is because on large installs generating the count for a full text search will make the interface too slow to use.