@Joe-K0OG The +n is only appended to the query and HB responses, not to every each message response. Do you think we should add that? It's easy enough to do, just a fahrvergnügen question.

Your missing ALLCALL query response is weird. I don't think I changed anything that would do that.

@Joe-K0OG The +n is only appended to the query and HB responses, not to every each message response. Do you think we should add that? It's easy enough to do, just a fahrvergnügen question.

I think it would be a good thing to add the +n to all responses, except the next-to-last one.

Your missing ALLCALL query response is weird. I don't think I changed anything that would do that.

I suspect that the ALLCALL issue is unrelated, but thought I should mention it in case it might be related, or is an otherwise easy fix in the same area of code.

73,
-Joe-
K0OG

@Joe-K0OG OK, I have added the pending count to the message response.

P.S. I noticed that the 160m frequency was changed. Was this intentional?

I changed that for 2.5.0 because everybody was using it anyway, and it gets it 3.5kHz above the FT8 dial freq.

We still have two problems that need to be addressed:

1. Messages remaining number is incorrect (the "+X" number). See example below.

2. @ ALLCALL QUERY MSGS does not work properly after the first query.
   A) If I @ ALLCALL QUERY MSGS, station responds properly showing messages waiting. However, any subsequent @ ALLCALL QUERY MSGS yields no response.
   B) Similarly to A), if I get all my stored messages, then new messages are stores for me, an @ ALLCALL QUERY MSGS yields no response.
   C) If the station storing messages for me closes/reopens, now @ ALLCALL QUERY MSGS works one time but not subsequently.
   D) In all cases, a direct QUERY MSGS to the station storing messages for me does work repeatedly.

Here is a log of what is happening from a test between two stations. The receiving station, picking up stored messages, is K0OG. The station storing messages for K0OG is KA0LOS, and has four outgoing message in the mail box. This is what K0OG sees when querying for messages (I added some explanatory notes with the "<==="):

14:30:50 - (1310) - K0OG: @ALLCALL QUERY MSGS
14:31:06 - (2056) - KA0LOS: K0OG YES MSG ID 99 +3 
14:31:23 - (1310) - K0OG: @ALLCALL QUERY MSGS  <===Second @ALLCALL fails to generate a reply
14:31:47 - (1310) - K0OG: KA0LOS QUERY MSGS  
14:32:06 - (2056) - KA0LOS: K0OG YES MSG ID 99 +3 
14:32:27 - (1310) - K0OG: KA0LOS QUERY MSG 99 VXT 
14:32:57 - (2056) - KA0LOS: K0OG MSG MSG 1 FROM KA0LOS NEXT MSG ID 100 +3 <===Should say "+2" here, not "+3"
14:33:28 - (1310) - K0OG: KA0LOS ACK  
14:33:49 - (1310) - K0OG: KA0LOS QUERY MSGS  
14:34:06 - (2057) - KA0LOS: K0OG YES MSG ID 100 +2 <===Now this displays the correct "+2" after a second QUERY MSGS
14:34:32 - (1310) - K0OG: @ALLCALL QUERY MSGS  
14:34:57 - (1310) - K0OG: KA0LOS QUERY MSG 100 JOG 
14:35:27 - (2056) - KA0LOS: K0OG MSG MSG 2 FROM KA0LOS NEXT MSG ID 101 +2 <===Should say "+1" here, not "+2"
14:35:58 - (1310) - K0OG: KA0LOS ACK  
14:36:25 - (1310) - K0OG: KA0LOS QUERY MSG 101 M48 
14:36:57 - (2057) - KA0LOS: K0OG MSG MSG 3 FROM KA0LOS NEXT MSG ID 102 +1 <===Should have no "+1" here
14:37:28 - (1310) - K0OG: KA0LOS ACK  
14:37:49 - (1310) - K0OG: KA0LOS QUERY MSG 102 O.B 
14:38:17 - (2057) - KA0LOS: K0OG MSG MSG 4 FROM KA0LOS 
14:38:38 - (1310) - K0OG: KA0LOS ACK  
14:39:13 - (1310) - K0OG: KA0LOS QUERY MSGS  
14:39:37 - (2057) - KA0LOS: K0OG NO 

Two things you can see from this:

1. The @ ALLCALL QUERY MSGS only works once unless the queried station is restarted.
2. The message numbering is not calculated properly.

73,
-Joe-
K0OG

@Joe-K0OG OK, I'll look at the count logic. Can you test the ALLCALL bug in the main branch to see if it's happening there too? I can't think of anything that I did here that would affect that.

@Joe-K0OG OK, I'll look at the count logic. Can you test the ALLCALL bug in the main branch to see if it's happening there too? I can't think of anything that I did here that would affect that.

Yes, I'll test that on main later this AM and let you know the result.

@Joe-K0OG OK, I'll look at the count logic. Can you test the ALLCALL bug in the main branch to see if it's happening there too? I can't think of anything that I did here that would affect that.

Yes, I'll test that on main later this AM and let you know the result.

@rruchte Yes, Rob, the problem with ALLCALL QUERY MSGS only working once is the same in main - you didn't break it! ;)

Does this part need to be moved to a new issue, or shall we keep it here?

73,
-Joe-
K0OG

@Joe-K0OG Awesome, thanks for checking that. Can you create a new issue for it? If 2.6.0 takes a while to release, I wouldn't want to hold up a fix for that by lumping it in with a new feature.

@Joe-K0OG Awesome, thanks for checking that. Can you create a new issue for it? If 2.6.0 takes a while to release, I wouldn't want to hold up a fix for that by lumping it in with a new feature.

I think 2.6 may take a bit, I'm still waiting on feedback on the API changes from kf7mix and others. Maybe some time after April 15?

Can you create a new issue for it?

Yes @rruchte I'll create a new issue.

73,
-Joe-
K0OG

I think 2.6 may take a bit, I'm still waiting on feedback on the API changes from kf7mix and others. Maybe some time after April 15?

I would expect that 2.5.x will have a pretty long lifespan and there is no rush to release 2.6.0 2.4.0 was a "get started" release, 2.5.0 came out pretty fast after that with major changes switching the name back to JS8Call. And of course, two patch releases that fixed complaints and/or bugs.

I think I would recommend going for annual minor point releases, or major releases, to give more time to thoroughly vet the code and issues. Maybe shoot for something like late summer/early fall. If glaring bugs are fixed it's now pretty trivial to patch the current stable and push a patch or maintenance release. For instance, the recent PSK Reporter fix could be considered a bug, current stable could be patched and push a 2.5.3 release for that, which many people would appreciate.

Patch releases are one thing. But I think it's bad practice to fire too many feature releases out the door too fast. Depending on what development takes place in the mean time, we may decide to go to a major release (3.0) on the next one, which IMO should've happened when the old Fortran decoder was scrapped and it went to C++.

@Joe-K0OG good catch on the count sent during transmission, I forgot that "mark as read" occurs in a callback after successful transmission. That's something I actually added, so I should have known better 😅. Fixed now.

@Joe-K0OG good catch on the count sent during transmission, I forgot that "mark as read" occurs in a callback after successful transmission. That's something I actually added, so I should have known better 😅. Fixed now.

@rruchte Yes, Rob, it's fixed now so that when you pick up messages in order, the countdown is correct.

However, there is an edge case: What if I don't pick up messages in order? If I have four messages waiting, and I pick up the second before I pick up the first, that first one is left "dangling" in terms of the counter. Here is a real-world example with four messages queued:

19:59:02 - (1310) - K0OG: @ALLCALL QUERY MSGS  ◊ 
19:59:30 - (1310) - K0OG: KA0LOS QUERY MSGS  ◊ 
19:59:46 - (1597) - KA0LOS: K0OG YES MSG ID 107 +3 ◊ 
20:00:10 - (1310) - K0OG: KA0LOS QUERY MSG 108 1/J ◊ <==Notice I picked up 108 instead of 107, out of order
20:00:36 - (1597) - KA0LOS: K0OG MSG TEST 2 FROM KA0LOS NEXT MSG ID 109 +2 ◊ <==I hoped that it would designate 107 +2 since I skipped 107 so it's left in the queue
20:01:08 - (1310) - K0OG: KA0LOS ACK  ◊ 
20:01:21 - (1310) - K0OG: KA0LOS QUERY MSGS  ◊ 
20:01:37 - (1598) - KA0LOS: K0OG YES MSG ID 107 +2 ◊ <==Now I'm back to message 107 +2
20:02:00 - (1310) - K0OG: KA0LOS QUERY MSG 107 -70 ◊ 
20:02:17 - (1598) - KA0LOS: K0OG MSG TEST 1 FROM KA0LOS NEXT MSG ID 109 +1 ◊ 
20:02:48 - (1310) - K0OG: KA0LOS ACK  ◊ 
20:03:02 - (1310) - K0OG: KA0LOS QUERY MSGS  ◊ 
20:03:17 - (1597) - KA0LOS: K0OG YES MSG ID 109 +1 ◊ 
20:04:05 - (1310) - K0OG: KA0LOS QUERY MSG 110 NF5 ◊ 
20:04:26 - (1598) - KA0LOS: K0OG MSG TEST 4 FROM KA0LOS ◊ <==It should indicate I have message 109 still in queue
20:04:48 - (1310) - K0OG: KA0LOS ACK  ◊ 
20:05:01 - (1310) - K0OG: KA0LOS QUERY MSGS  ◊ 
20:05:17 - (1597) - KA0LOS: K0OG YES MSG ID 109 ◊ <==There, now it's reporting that 109 is waiting
20:07:08 - (1310) - K0OG: KA0LOS QUERY MSG 109 4JR ◊ 
20:07:28 - (1597) - KA0LOS: K0OG MSG TEST 3 FROM KA0LOS ◊ 
20:07:48 - (1310) - K0OG: KA0LOS ACK  ◊ 
20:07:59 - (1310) - K0OG: KA0LOS QUERY MSGS  ◊ 
20:08:16 - (1598) - KA0LOS: K0OG NO ◊ 

I realize that this is an unlikely "edge" case, so if you choose to not address it, no big deal as I think 99+% of the time people will pick up their messages in order, as displayed by the holding station.

73,
-Joe-
K0OG

@Joe-K0OG so this is an issue with the lookahead NEXT MSG ID, not the +n, right? The lookahead picks the next message ID available after the one being transmitted, should we rethink that?

What we have now is an implementation of the linked list concept.

@Joe-K0OG so this is an issue with the lookahead NEXT MSG ID, not the +n, right? The lookahead picks the next message ID available after the one being transmitted, should we rethink that?

What we have now is an implementation of the linked list concept.

@rruchte Rob, I was thinking it would count the number of remaining message in the mailbox, then list the message number for the one at the top of the list, rather than just incrementing the message number for the last one read. Is that too much trouble to do? If so, not a big deal in the real world, but it does leave the messaging vulnerable to someone missing a message if they read them out of order (most likely due to a typographical error).

73,
-Joe-
K0OG

@Joe-K0OG The next message ID works differently when retrieving a message than it does when querying messages. When querying messages, the ID returned is the first available message. When retrieving a message, the next ID is the next available message after the one that is being returned.

The +n count does not take the message position into consideration, it's the total count of available messages. So you could jump into the linked list of available messages in the middle, pull all of the messages until the end, and still have a count that indicates the first half of the list the you didn't pick up.

We could rework this, we just need to know what the new requirements are.

We could rework this, we just need to know what the new requirements are.

@rruchte What I'm thinking is this:

1. At the end of receiving a message, the remaining message counter counts the number of messages remainging in the mailbox, decrements it by one, and will report that as the "+n" at the end of the received message (this seems to work properly now, as you mention).

2. At the end of receiving a message, the first (oldest) message number in the mailbox list of messages will be reported as the next message number to retrieve, regardless of what that message number is (in other words, that message number is independent of what the last message number was, but is only based upon what is stored in the mailbox for me).

Does that make sense? Is it worth the effort to rewrite code to do this? I think so, but I'm not the one having to rewrite code, ha ha!

73,
-Joe-
K0OG

@Joe-K0OG I think that would only require changing ">" to "!=" in a couple of SQL queries.

@Joe-K0OG I think that would only require changing ">" to "!=" in a couple of SQL queries.

See, that's why YOU'RE the man! I might think I know what needs to be done, but don't know HOW to do it! Ha, ha! I hope it's that simple.

73,
-Joe-
K0OG

Ha! Yup, that should be it. Give that a try and see if it's what you're wanting to see.

Ha! Yup, that should be it. Give that a try and see if it's what you're wanting to see.

That's it @rruchte !!! Regardless of message pick-up order, the correct number of messages waiting and the correct next-available message number are displayed. Flawless!

Thanks Rob, I think we can go with this one and close it now.

73,
-Joe-
K0OG

Fixes #191