Yes, it appears screwed up again. There is a problem where after a while a 'decode off' message will be lost between JTDX and Logger32. This causes a chain reaction whereby UDP messages are no longer processed, and as DX Spots are not processed during the JTDX 'decode on' part of the cycle they queue. Essentially Logger32 freezes. The logic has been modified, and is currently being tested. Hopefully I can release it this evening of tomorrow.
Now this raises the question. How/why does a UDP message get lost? And, how/why are some users experiencing periodic unexpected crashes of Logger32? I have never experience any of these symptoms. My theory is that Internal JTDX settings (and my bad code) is the root cause. It is my strong recommendation that JTDX initially be setup as follows:
1) Turn OFF the SWL mode option.
2) On JTDX click DECODE | FT8 THREADS. Click AUTO.
3) On JTDX click DECODE | FT8 DECODING | WIDEBAND DECODING. Click FAST.
4) On JTDX click DECODE | FT8 DECODING | NARROW FILTER. Click FAST.
5) On JTDX click DECODE | FT8 DECODING | DECODING CYCLES. Click 1.
6) On JTDX click DECODE | FT8 DECODING | QSO RX FREQ SENSITIVITY.
7) On JTDX click DECODE | FT8 DECODING | DECODER SENSITIVITY. Click MINIMUM.
8) On JTDX click DECODE | FT8 DECODING. UNcheck both LATE START OF DECODE and WIDEBAND DX CALL SEARCH.
9) On JTDX click DECODE | FT4 DECODING. Click FAST.
With these settings, my very old i5 processor peaks at 30% utilization during the JTDX 'decode on' period. While simultaneously processing 1500 DX Spots/minute. Never a crash (ever), and even v4.0.258 runs perfectly.
Use these as the entry point, and see if your Logger32 stability improves and what impact this has on your JTDX performance.