Unusual Stoppage of DX spots
I recently experienced an unusual stoppage of all incoming spots being posted to the spots window and to the UDP Band map which was full.. All other functions appeared normal..
To explain how this happened: While leaving L32 on and running with the UDP bandmap open with JTDX and then going into another room while it was running for several hours I found after returning that all dx spots and incoming activity had stopped.
Seeing that the UDP band map was completely filled and then hitting the clear function activity immediately started with several hours worth of DX spots rolling in scrolling away for several minutes.
Is this a buffer condition having reached a completely full condition for the UDP bandmap?
If so can the UDP band map be made to flush after either reaching a near full size or on a time basis?
I dont consider this to be a major issue but nice to know FYI thing as to whether the UDP Bandmap should be closed by the operator if they are going to leave things running when not at the computer locally.
Perhaps I have missed a setting to clear the UDP Bandmap periodically..
If this is not a condition of L32 or the UDP band map, then it must be a memory problem on my computer and I will have to remember that in the future to close the UDP band map, but I have never experienced this action before.
This BTW occurred on the latest version just a few days ago as I always allow L32 to update.
Gary - W3GLD
toggle quoted messageShow quoted text
Gary, the UDP BandMap buffer is something like 400 rows. Every time a new callsign is decoded the buffer is checked. If the callsign is not in the buffer and the buffer is not full the callsign is added. I the buffer is full, the oldest decoded callsign is deleted an the new one added. The CLEAR menu on the UDP BandMap window clears the entire buffer. So much for the buffer, now to the actual UDP BandMap. The number of rows is dynamic, depending on the height of the windows form. As every WSJT/JTDX decode cycle completes, the newest decoded signals populate the visible rows. You can see the effect by changing the height of the UDP BandMap watching which decoded callsigns are visible.
I have no idea what you saw, or thought you saw, but I doubt it was a buffer overflow. Logger32 would scream and shout with "The sky is falling ..." error messages, then freeze. I am not doubting or questioning this error report. Clearly something is wrong, but without some pointers, I have no idea where to start looking. For now, all I can suggest is that you click the VIEW menu and make sure the ENABLE ERROR TRAPPING option is checked. This option turns on an additional level of error testing that may reveal what is wrong. SeventyThree(s).
On July 22, 2019 at 5:03 PM Gary <wa3nwl@...> wrote: