On 14/07/2021 3:30 am, Greg, KM5GT wrote:

To complete the picture, this is what I am seeing.� The "stars" below the program header is my background.



73, Greg, KM5GT

If your expecting to see the Callsigns displayed under the menu bar of that window, you're out of luck. The callsigns display grid embedded in the main JTAlert window was removed starting with JTAlert 2.50.0. The callsigns are now displayed in their own dedicated window. Use the view menu to open the Callsigns window.

BTW, you image shows JTAlert displaying the Band & Mode in the titlebar, that indicates that comms with WSJT-X is working. You don't appear to have the same problem as others have been experiencing.

de Laurie VK3AMA

I'll hold off on making this change and instead see how version 2.50.2 behaves.

Jim  W9FI

On 7/13/2021 4:49 PM, HamApps Support (VK3AMA) wrote:

On 14/07/2021 9:34 am, Joe Subich, W4TV wrote:

If you are using multicast ("WSJTX UDP Multicast on Loopback" checked),
you need to use a Multicast address in WSJTX -> Settings -> Reporting ->
Network Services.  See: Help -> WSJT-X UDP Setup in JTAlert.

Joe,

That is not the case. The "multicast on loopback" setting can be left enabled when running unicast WSJT-X.
JTAlert ignores the setting if WSJT-X is detected not running multicast.

de Laurie VK3AMA

On 14/07/2021 9:34 am, Joe Subich, W4TV wrote:

If you are using multicast ("WSJTX UDP Multicast on Loopback" checked),
you need to use a Multicast address in WSJTX -> Settings -> Reporting ->
Network Services.  See: Help -> WSJT-X UDP Setup in JTAlert.

Joe,

That is not the case. The "multicast on loopback" setting can be left enabled when running unicast WSJT-X.
JTAlert ignores the setting if WSJT-X is detected not running multicast.

de Laurie VK3AMA

> WSHJT's UDP server address is 127.0.0.1. Its UDP server port is 2237.
> Its secondary server is disabled.  The "Accept UDP addresses", "Notify
> on accepted UPD Request", and "Accept UDP Request Restores Window"
> options are all checked.
>

On JTAlert, the Select menu's "WSJT-X  UDP Multicast on Loopback"
option is checked.  In its Settings/Applications/WSJT-X / JTDX"
section, all of the options are selected except for "Resend WSJT-X
UDP Packets..."

If you are using multicast ("WSJTX UDP Multicast on Loopback" checked),
you need to use a Multicast address in WSJTX -> Settings -> Reporting ->
Network Services.  See: Help -> WSJT-X UDP Setup in JTAlert.

Multicast address ranges are: 224.0.0.1 to 224.0.0.255  and
239.255.0.1 to 239.255.255.255.  The recommended address is
224.0.0.1

73,

   ... Joe, W4TV


On 2021-07-13 6:27 PM, Jim Wysocki wrote:

I've been using JTAlert with WSJT-X for several years without any problems at all, until last night when I updated to version 2.50.3, 64 bit.  Several problems now have appeared.

There is a general sluggishness to JTAlert's main window.  In contrast to all of the others on the desktop, when this one is grabbed and moved around, there is a 1 or 2 second delay in its response.  The same is true of when it has focus and the mouse is scanned across the tabs from Alerts to Help.

The call signs windows that was immediately below the main window in the old version has disappeared, and pressing F3 will not make it show up. The Decodes window can be made to appear by clicking on its option off of the View tab, but it has problems.  The decoded transactions that come to it from WSJT-X appear late and at intermittent times.  Every once in a while it will partially synch with WSJT-X, generally showing up to four of the latest callsigns that WSJT just decoded.  Occasionally JTAlert will grab more of them.  Most of the time it runs between one and six time slices behind WSJT.  Then it will grab about four of the latest transactions before locking up again. It cannot respond in real time with the data feed from WSJT-X.

Here is some background information for the problem analysis.

I am running a fully-updated Windows 10 Professional (64-bit) machine, an i5 with four processors at around a 3.3 gig speed and 16 gb of memory.  Task manager shows no memory or processor bottlenecks.  Windows desktop Dotnet runtime version 5.0.7 64 bit has been installed without any problems.  The JTAlert Framework Check displayed the "Good News" screen at the time that version 2.50.3 was installed.

Both WSJT-X and JTAlert have been whitelisted on PCMatic SuperShield. The Windows Defender firewall has been directed to allow the HamApps software apps to pass through it. Just to make sure I've also disabled Defender from running on the computer's private network.

WSHJT's UDP server address is 127.0.0.1. Its UDP server port is 2237. Its secondary server is disabled.  The "Accept UDP addresses", "Notify on accepted UPD Request", and "Accept UDP Request Restores Window" options are all checked.

On JTAlert, the Select menu's "WSJT-X  UDP Multicast on Loopback" option is checked.  In its Settings/Applications/WSJT-X / JTDX" section, all of the options are selected except for "Resend WSJT-X UDP Packets..." . The value in the greyed-out IP address is 127.0.0.1, and the greyed-out UDP port's value is 2233.  None of these six checked options appears to control information in the Decodes screen. As mentioned before, the Callsigns Window is no where to be seen.

Since this latest version was installed over the previous one, I used the Windows "Add or Remove Programs" utility to remove JTAlert, and then installed it again via

It appears to be that the transaction flow from WSJT and JTAlert is getting disrupted in some way, but I can't determine how this is happening.  I'm at a loss as to where to proceed from here so I need some advice.  What can be done next to diagnose and resolve this problem?

Thanks and 73,  Jim  W9FI