And below is another response from HRD support. Neither message touches on a HRD defect. Wish they would admit to it as it is causing a lot of effort on others trying to fault isolate.
You need to disable that option in WSJT-X and in JTAlert (port 2333)
Let JTAlert write to the Database (also disable QSO Forwarding in Logbook)
Then there are no issues at all.
Ham Radio Deluxe Support Technician
On Tue, Jan 12 at 5:15 AM , Ronald Panetta <ron@...> wrote:
I respectfully disagree as it has everything to do with HRD and possible JTAlert. JTAlert CAN post QSO information via UDP broadcasts to port 2333. See the attached screen snapshot of JTAlert Last QSO API settings screen. In both David's case and my case, the highlighted QSOs were passed by JTAlert to via UDP port 2333 and subsequently picked up by HRD and logged with all fields but the date. In my second post I provide the data field of a UDP/2333 packet picked up by Wireshark (Ethernet sniffer) with the QSO data. In both our cases, the date field of that QSO is missing per David's screen snapshot.
Now it takes two to tango so JTAlert generates the UDP/2333 packet and HRD picks up the UDP/2333 so the failure could be on either end. I'm starting the query with HRD. BTW, I contacted David directly to see if he ever got a resolution, indicated he was unable to get the issue resolved so his solution was to abandon HRD.
On Wed, Jan 13, 2021, 10:05 PM Chris VK2BYI <chris@...
There is a known defect in HRD Logbook where UDP broadcasts received on the QSO Forwarding for WSJT-X port may not log correctly depending upon the ADIF field order.
Of course, the field order in ADIF formatted UDP payloads shouldn't matter, and the defect has been fixed and will be released in the next update of HRD.
In the meantime, you can use the HRD V5/V6 logging interface in JTAlert, until the next release of HRD when you can revert to using the Last QSO API broadcasts again.
Stay safe and healthy.