= Сообщение: 745 из 1367 ============================================= UTF-8 = От : mark lewis 1:3634/12.73 07 Apr 19 13:08:28 Кому : Richard Menedetter 07 Apr 19 13:08:28 Тема : goated FGHI : area://UTF-8?msgid=1:3634/12.73+5caa2e94 На : area://UTF-8?msgid=2:310/31+5ca9f46d = Кодировка сообщения определена как: CP437 ================================== Ответ: area://UTF-8?msgid=2:310/31+5cb435d9 ============================================================================== On 2019 Apr 07 14:51:34, you wrote to me:
RM> If I read them in golded all will be marked read,
ok, technically, they're not "marked as read"... their message number is simply less than or equal to the lastread pointer in the JLR file... since their message number is less than or equal to the lastread pointer, they are drawn in GoldED with a different color... AFAIK, that's all it is that is doing that different colors thing...
1. how many messages to you actually have in the JAM area in question? 2. what is the lowest message number indicated in GoldED? 3. what is the highest message number indicated in GoldED? 4. has the JAM base had messages deleted from it for being too old? 5. are the message numbers the same between GoldED and GoatED for the same message(s)?
here's where i'm going with this... i'm starting to wonder if the base message number (aka offset message number) in the JHR is not being accounted for when the JLR file is being written... in other words, if the base message number is 0 then the first message in the base is 1... if the base message number is 250, then the first message in the base is 251... if this base message number in the JHR file is not being accounted for, then the number written to the JLR file will be too small since it leaves out the base message number... GoldED would think you have not read that high because of this...
NOTE: i may be off by one in the above... i don't recall if a new empty JAM area starts with 0 or 1 as the value in the JHR... the point is that this base message number (aka offset) should be taken into account one way or the other...
RM> So the unread pointer is updated, but the messages in the JAM base are not RM> marked as read. (and show up in a different color, as golded sees them as RM> unread)
as above and as we dig more into this problem and gain more details, this would seem to indicate that the pointer is not being written to the JLR file properly... either that or GoldED is doing something else outside of the JAM spec to keep up with them... we already know that it is doing a WeirdThing<tm> when deleting messages... that weird thing allows the messages to be easily undeleted but it is outside of the JAM spec operation...
ml>> right... so the problem does appear to be something with the ml>> last/high read pointers
RM> No, the lastread pointer is updated correctly.
it would seem not if GoldED isn't listing the messages properly... but it could be something else, as mentioned above...
ml>> seems to have been done properly... i'm assuming that you do only ml>> have 328 (or whatever that number was) messages in the area in ml>> question? now i'm curious about that JLR data again and which of the ml>> two programs was the last one used which would have written those ml>> counters to the file...
RM> The JLR file is fine.
do you have another JAM capable local sysop reader you can use to access your JAM bases with? does it show the same problem as GoldED? if you do have one, it would point more toward where the problem is... maybe try TimED or MsgED?
)\/(ark
Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... What we have here, is a NEED to communicate! --- * Origin: (1:3634/12.73)
