Re: Unread Threads Marker Problem
What Skald described is expected behaviour. The server only permanently tracks the most recent public and private message you've read for each game you visit. Actually, it also tracks the most recent private and public message that you can see, which is used for the indicators on the main menu as well as the starting point for when you're in a game when you don't have any cookies for that game.
That's enough for the server to track, that's 4,163,940 things being tracked right there. Plus the user and game id, so in a way 6,245,910.
As alluded to above, everything else relies on cookies. Visiting a game after a relog (or new OS, new browser, clearing cookies etc) the system will use the "most recent message I've read" database entry as the basis for what is read (anything equal to or lower than that) and unread (anything greater).
Once you start reading individual threads it uses cookies to track any "holes" in the read list. If you read the next newest thread then there's no gap, the read threads are consecutive, but if you read the newest and leave a few others below it unread, then there's a hole and cookies are used to track those unread.
Possibly confusing, but think of it this way; any flame icon below the topmost shield icon is tracked via a cookie. Notices, for this purpose, are calculated based on where they should appear (chronological), not where they are (stuck to the top).
Rinse and repeat this for every game, and then double it -- once for the main game threads, and one for private threads.
This is all stored in two cookies that looks a mess to the untrained eye (perhaps because it is a mess). It's basically a long list of games you visit and what's unread (that would otherwise be considered read).
Cookies also shouldn't get too large as the browser has to send them to the server for every page you visit on the site, plus there's actually a hard limit of 4096 bytes (characters). Sending lots of cookies can slow down the browsing experience. Older browsers have issues with about 1024, so that's the limit we keep within.
1024 means we can store, approximately, 100 unread messages before it starts to get too long. In that instance we trim the list down until it's under 1024 characters in length, removing the oldest unread first.
Long winded and complicated to explain, imagine what it was like to code!
So, if you have a lot of unread messages in a lot of games then you can see things get messy. If around 100 threads being tracked (remember these are only unique unread ones) then it has to start chopping things off to avoid browser issues.
If you don't relog when changing computers then the old tracking cookies will be left behind, and threads will be noted as unread when you read then on the other machine.
Weird read/unread problems will remain unless you relog when changing computers. This is by design and will never be fixed. It is not feasible for the server to track 3,524,443,271,568 permutations (what would be required to track 1,050,397 threads for 93,204 users). For those who are curious, that's 3.2 terabytes.
As for those seeing the issue when only using one computer, a relog will general get things back in order (more or less). Everything becoming unread (or unread messages becoming read) normally indicates that the cookie that tracks these things has been lost (or corrupted, but you'd hope such things wouldn't happen in modern browsers). Not really any other constructive feedback I can provide on that at this stage.