Do you think so, Globalopper?

Actually I would prefer a consistent solution to avoid confused users.

What about disabeling the mark as read instead?

newbe

Very good point, krikkert!!! 

What about a second option in the admin center if the logs should be written when "mark as read" is switched on?

Well it makes sense to make them all store the last post when you hit mark as read but it will make a large .log file.
Currently mark all as read just sets each forum as being read so thats usually only a couple lines. But if we were to do it with this mod you would need to make a line in the .log file for every thread on your board. So a board like this one would need 5000+ lines in every users .log file and that would probably take a while to parse through... It would be nice to do but I think not practical. But we won't know for sure until we try though.

If it is going to make the board slower, then I'd say probably should leave well enough alone...

I'm not a coder, so I don't know...  But I've got a question for you...  What is to stop this thing from getting too big anyway?  What happens to the log 500 threads later, or even 5000 threads later?

Where can I get the beta of this mod?  I have a sp 1.1 board I am willing to test it on........

DUH  Thanks.

*Splungent slinks into his corner in embarrasment*

I think the "marking old threads as new" was intended as a feature rather than a problem (at least according to a post I read a while ago on the YaBB forum.)


At the moment, when you view the message index, YaBB has to load the users log, then check to see if each message is new or has been read, then check to see if the forum or board has been marked as read.

When you view a thread, the information in the log file has to be updated. This means reading in all the entries again, and modifying or adding an entry for the thread being viewed, then saving the new information.

If you have a lot of enties in the users log, lots of users, and lots of threads, all this reading and writing will take time.

Compression may not help in these circumstances because everytime someone views a thread, you would have to load the users log, uncompress it, update the details, re-compress it then save it back to the server. You may gain speed in the read-write stages at the expence of processor usage in the compress-uncompress stages.

I really don't know enough about it to know for sure. You could try asking Michael Prager who I believe has tried using Gzip compression on this board, but I'm not sure how it was implimented.