The timestamp is in the current file as you say, but the messageID has changes from one file to the other. The first record (4097266.msg37354230) still exists and reading the post seems to have moved section. The remaining 8 are now deleted (propably after moving them first).
This is annoying 
I use this to add new lines to my old file:Code:
comm -1 -3 <(sort merit.all.txt) <(sort merit.today.txt) > merit.new.txt
But, this indeed fails on the lines you've mentioned:
Code:
1526466697 1 45212.msg37354230 1192397 209286
1526466697 1 4097266.msg37354230 1192397 209286
It refers to this post, and my script outputs this:1526466697 1 4097266.msg37354230 1192397 209286
Code:
1650. 18 Merit received by aleix (#209286) from 3 unique users in 9 transactions
In reality, aleix has received 17 Merit.Quote
I checked and there are 499 cases of timestamps with 2 or more associated TXs in the file, therefore going for the complete record PK.
Some of these can be explained by double clicking the Merit button, like these:Two times 1 Merit from Syndikat to undercomander13 for this post.
Two times 4 Merit from minerbro to Piston_82 for this post.
~more~
Two times 4 Merit from minerbro to Piston_82 for this post.
~more~
What this entails is that changes to records older than 120 days may not be consistent in our ALT aggregate databases.
For example, as seen above, some merited TXs may change section or get deleted, but the ALT aggregate database will still point to the original message once the TX is outside of the 120 window frame.
I'm not sure yet how to fix my "all time copy" of theymos' data. I don't really mind of a few links are incorrect, but the amounts should add up exactly. I think I just have to find where the files overlap and copy it without using the comm command.For example, as seen above, some merited TXs may change section or get deleted, but the ALT aggregate database will still point to the original message once the TX is outside of the 120 window frame.