Jim, what makes you think memory is being exhausted? Have you eliminated any other processes or system services that might be consuming excessive memory?

#DXLAB #HamSpots #FT8

Jim, you said several things in your OP that seem wrong to me, you have failed to clarify what you are doing and when ask to you reply with unrelated details. Let;s try again with some specific querie

Hi Jim, the secondary ports are not relevant. The two different ports for each WSJT-X instance should be fine so long as no other application is using those ports. In you OP you talked about setting u

Hi Jim, this is nothing to do with DXKeeper, JTAlert transfers logged QSOs to DXKeeper regardless of how many WSJT-X and corresponding JTAlert instances you have running. I am not sure you understand

Hi Jim, the part above seems wrong. For WSJT-X you can copy the shortcut used to start it and add a --rig-name= option to its command line, for JTAlert all you need do is start JTAlert a second time.

Hi Bill, make sure you have the WSJT-X option "Settings->Reporting->UDP Server->Accept UDP requests" checked. 73 Bill G4WJS.

Hi Jesús, nothing should have changed unless you are using the latest WSJT-X v2.3.0 RC2 release candidate. In that case you must either check the JTAlert option "Menu->Settings->WSJT-X UDP Multicast o

Hi Jesús, why have you changed to a unicast address? Your original setup is OK. 73 Bill G4WJS.

Hi Bob, do you have correctly functioning CAT control? 73 Bill G4WJS.

Hi Laurie, Users pick the address, they can use any appropriate one. What is appropriate may depend on their requirements, i.e. do other applications need to access WSJT-X multicast traffic on a diffe

Laurie, as I explained off list, 224.0.0.1 is a special multicast address known as the "All Hosts" address. The 224.0.0.0/8 block of addresses is also special as they are never routed. 224.0.0.1 speci

Laurie, the OP claimed to be using 239.0.0.1, that is most definitely *not* in the 239.255.0.0/16 block of multicast addresses!

Hi Gene, that's not necessary although it could tale up to 15 seconds after the change is saved before JTAlert sees the WSJT-X traffic.

Hi Tom, you appear to be one of the users using an inappropriate multicast address that has caused this change to be made. Until a version of JTAlert is available that will receive multicast traffic o

Hi Al, this is expected. WSJT-X no longer sends multicast UDP datagrams on the default network interface. There is a JTAlert update on the way to account for that, until that is available you can *cha

Hi ian, if you use the option to dock the JTAlert window to the WSJT-X main window it will not matter which is which.

Mike, if I understand the process correctly it is not wholly down to DXKeeper. JTAlert requests that DXKeeper do a single QSO upload to LoTW when it passes a QSO to DXKeeper. It is not controlled by D

Hi Laurie, this may not be relevant and your comment above just be using incorrect terminology, but wide-strings in Windows are not utf-8, they are 16-bit characters encoded with utf-16 little-edian U

Craig, check the release notes: https://hamapps.com/php/notes.php?file=jtalert

Hi Tom, do you have the same UDP server settings in each of your WSJT-X configurations ("Settings->Reporting->UDP Server")? 73 Bill G4WJS.