HamApps Support (VK3AMA)
On 21/06/2021 4:47 am, The Romagni's wrote:
ok... I might have found something, I rebooted as you suggested, then launched dxview and it behaved as planned - then i lunched wsjtx and the jtalert then the issue came back! so looks like the issue is with in jtalert... now let me see if I can find the why there...
If JTAlert is repeatedly sending the WSJT-X DXCall to DXView it will be because JTAlert is getting repeated updates on the DXCall. Based on recent similar issues, the problem is very likely incorrect configuration in JTAlert, specifically, the "Resend WSJT-X UDP packets..." setting, under the "Applications -> WSJTX/JTDX" section of the Settings window, is enabled with the port incorrectly set to the same port that JTAlert is listening to for UDP data from WSJT-X.
Typically these incorrect setups have the port set to 2237 which is the default port that WSJT-X is sending to. A feedback loop is created where JTAlert is repeatedly resending the UDP packets back to its input.
This has become a common enough problem in recent weeks I am starting to believe that there is some incorrect setup instructions floating around and people are applying these changes without any understanding of what they are doing. If the changes were made to fulfill a specific multi-app setup, it would not be working, so it is best to just turn off that setting or at a minimum change the port to something other than 2237.
FWIW, by default this setting is NOT enabled and the default port is 2334. Any changes from these defaults can only happen by the end-user modifying them.
Alternatively there is another WSJT-X interacting application running and it is re-sending the UDP data to port 2237 (or whatever the UDP Server port is set to in WSJT-X).
de Laurie VK3AMA