Date   

locked Re: 2.50.3 problems

HamApps Support (VK3AMA)
 

On 14/07/2021 6:56 pm, Dave Miller via groups.io wrote:
you are right. JTAlertV2.Manager.exe is constantly running and dropping out. I checked Kaspersky and it is set to a trusted app. Not sure what else to do but will see if there are any Windows security settings blocking it.

Dave G6AWF

JTAlertV2.Manager stopping and starting every couple of seconds indicates that the Manager process is faulting and shutting down and the main controlling JTAlert process is starting it up as it was detected not running. JTAlert has always done this and it checks for the presence of the Manger every 2 seconds.

I can make this type of fault happen at will by simply running JTAlert against in incorrect NET runtime, either the wrong bit version or having the NET Runtime installed rather than the required NET Desktop Runtime.

Open up Windows event viewer and see if there are errors recorded there under "Windows Logs -> Application". This is from my machine when I try and run 32bit JTAlert install with the 64bit NET Desktop runtime installed.

   

Let me know what you find.

de Laurie VK3AMA


locked Re: 2.50.3 problems

Dave Miller
 

Thanks Bill, you are right. JTAlertV2.Manager.exe is constantly running and dropping out. I checked Kaspersky and it is set to a trusted app. Not sure what else to do but will see if there are any Windows security settings blocking it.

Dave G6AWF


locked Re: .NET v 5.0.8 x64

Jacques F1VEV
 
Edited

Likewise 5.0.8 64 Bit no issues Thanks F1VEV


locked Re: JTDX issues with latest JTAlert release. #JTDX

Alan Sorum WL7CG
 

I backed off to 2.50.2 and it's working fine.

73 Alan WL7CG


locked Re: New JTalert 2.50.3 missing callsign window

Robie - AJ4F
 

I installed today's windows update as well as the NET5 Desktop Runtime 5.0.8 X64 and still am not able to open the Callsigns Window.  Task Manager shows that  JTAlertV2.manager.exe is not running on my system.    I have set up an exclusion in windows defender for the HAMAPS folder.  This change did not result in the callsigns window becoming visible nor JTAlertV2.manager.exe running.

I'll provide any additional information requested to assist in resolving this issue.

Robie - AJ4F



On Tue, Jul 13, 2021 at 2:55 PM Dan K2IE via groups.io <dan=islenet.com@groups.io> wrote:
Same here...20.50.3 64 bit installed today and I no longer have the callsign window.


locked Re: 2.50.3 problems

Andy k3wyc
 

I finally got back to a what appears to be a usable and stable configuration by using a restore point prior to 2.50.0 installation and re-installing Net framework 5.0.5.  2.50.5 would not run with Net framework 5.0.7 and 2.50.0 was unstable with it.  Just installing 5.0.5 over 5.0.7 didn't fix the problem.  Had to go back to a restore point before the computer ever saw 5.0.7.

Andy, k3wyc


locked Re: Problems with JTAlert latest install

Jim Wysocki
 

Laurie, here's one more item that was buried in my notes to myself.  Task Manager saw that HamApps "Decoder" was running consistently, but that HamApps "Audio and Visual Alerts for WSJT-X (32 bit)" was appearing and disappearing from the its list of active apps.  Audio and Visual Alerts ran on a consistent cycle, at about 3 seconds on and 3 seconds off, repeatedly.

Maybe this is typical behavior or not; I can't tell but you'll know the answer.

73,  Jim  W9FI

On 7/13/2021 6:18 PM, Jim Wysocki wrote:

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



locked Re: Problems with JTAlert latest install

Jim Wysocki
 

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



locked Re: Problems with JTAlert latest install

Jim Wysocki
 

Thanks for your reply, Joe, and hello again on a different forum.

I tried changing the UDP address to 224.0.0.1 without success, but that was before I turned off Windows Defender and got it out of the way.  I'll change the UDP address accordingly and report back tomorrow on the results.  The reconfiguration will have to wait until the morning because the local weather won't cooperate with the testing process.  It's  going to be an active night of continuing rain, lightning and thunder.  The station has been disconnected until the WX clears up early tomorrow morning.

73,  Jim  W9FI

On 7/13/2021 4:34 PM, Joe Subich, W4TV wrote:

> 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










locked Re: Problems with JTAlert latest install

Jim Wysocki
 

Thanks for the quick response.  Here are the answers to your questions.

The CPU usage never topped 24%, with most of the load coming from WSJT-X's decoding engine at 12% -14%.  JTAlert's usage typically never rose about 1.5%.  In terms of memory, everything running on the computer only brought the memory percentage above a few percent.  Memory usage never got above the single digits.

I did two PC restarts to see what would happen.  There was no change in JTAlert's behavior, from before to after the restarts.

Thanks for the explanation of the user interface redesign and the replacement of the old call signs window with the stand alone, resizable one.  I presume that it's different from the Decodes window.  I've seen "Decodes" but not "Call Signs".  Hopefully that situation will change soon.

I was running version 2.16.14 before the 2.50.3 install.

I hope these clues help in the problem solving process.

73,  Jim  W9FI


On 7/13/2021 4:31 PM, HamApps Support (VK3AMA) wrote:
On 14/07/2021 8:27 am, 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


Jim,

Thanks for the detailed message. You have answered some of the questions I would have asked. Thanks for making the effort to read the group messages and attempt diagnosis before posting.

What is the CPU usage of JTAlert when it is sluggish or non-responsive?

Have you done a PC restart?

I note you said the "The call signs windows that was immediately below the main window in the old version has disappeared". That is correct, that display was retired when JTAlert 2.50.0 was released as it includes a standalone resizable no callsign display limit window called the "Callsigns" window.

Since you asked about the old inbuilt callsign display suggests that you upgraded from a pre 2.50.x release of JTAlert. Is that the case? If so what version were you running before the 2.50.3 install?

de Laurie VK3AMA



locked Re: Callsign window gone after update to 2.5.3

W9WO
 

Laurie.
 
 Based on your suggestion of people having problems with 2.50.3 to revert back to 2.50.2 got me to thinking. I went from 2.50.0 to 2.50.3. As previously mentioned I reverted back to 2.50.0 today and it was again working fine. So I decided to try 2.50.2 per your advice. I downloaded 2.50.2 x 64 and it also works fine. I also tried the suggested "2021-07   .NET 5.0.8  x64 Client   KB5004698" which is what I'm now using and didn't fix 2.50.3 but works fine with 2.50.0 and 2.50.2. My problem is only with 2.50.3.
I just wanted to provide some more information on my specific situation.
 
73,
Darrell W9WO
 
 


locked Re: .NET v 5.0.8 x64

kb2m@arrl.net
 

Yep. I just installed 5.0.8 64 bit and all is working here also...


73 Jeff kb2m


On 7/13/2021 7:19 PM, HamApps Support (VK3AMA) wrote:
On 14/07/2021 8:06 am, Stephen Taylor - K6SJT wrote:
FYI - Today's Microsoft Patch Tuesday updates included:

2021-07�� .NET 5.0.8� x64 Client�� KB5004698

Implemented all of today's Microsoft updates with no negative operational issues experienced using latest versions of WSJT-X and JTAlert.

Stephen Taylor - K6SJT

Tnx Stephen.

JTAlert is working correctly with 5.0.8. Tested with both x64 & x86 installs.

de Laurie VK3AMA


locked Re: Problems with JTAlert latest install

HamApps Support (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



locked #Announcement : Users with JTAlert 2.50.3 problems try downgrading to 2.50.2 #Announcement

HamApps Support (VK3AMA)
 

Users who are having problems with JTAlert 2.50.3 please try downgrading to 2.50.2.

I don't know the cause of the problems that some 2.50.3 users are experiencing. None of the Test Team are experiencing problems. I have personally done numerous installs with both x86 & x64 versions on 3 PCs here trying to reproduce the failures that have been reported. Nothing I have tried has resulted in a failure.

If you experienced 2.50.3 problems please check your Windows Event Viewer to see if it has any problems recorded for JTAlert.

At this time, I am blind to what is happening, so your best course of action is to rollback to JTAlert 2.50.2

de Laurie VK3AMA



locked Re: 2.50.3 problems

HamApps Support (VK3AMA)
 

On 14/07/2021 4:02 am, Chris Morrison wrote:
Looking at task manager JTalertV2.Manager is running but its being reported as 32-bit despite installing the X64 version of JTalert.



How to I do a clean install of JTalert?

That image is correct. The main JTAlert.exe executable is 32bit only regardless of the which installer was used, x64 or x86. The critical component is the JTAlertV2.Manager.exe executable which comes in two variants depending on the installer, 32bit & 64bit. Thus the need to match NET 5.0.x with the JTAlert installer bit type.

de Laurie VK3AMA


locked Re: Problems with JTAlert latest install

Joe Subich, W4TV
 

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


locked Re: Callsign window gone after update to 2.5.3

Robert Woltag
 

I am having the same issue.  Following..


locked Re: Problems with JTAlert latest install

HamApps Support (VK3AMA)
 

On 14/07/2021 8:27 am, 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


Jim,

Thanks for the detailed message. You have answered some of the questions I would have asked. Thanks for making the effort to read the group messages and attempt diagnosis before posting.

What is the CPU usage of JTAlert when it is sluggish or non-responsive?

Have you done a PC restart?

I note you said the "The call signs windows that was immediately below the main window in the old version has disappeared". That is correct, that display was retired when JTAlert 2.50.0 was released as it includes a standalone resizable no callsign display limit window called the "Callsigns" window.

Since you asked about the old inbuilt callsign display suggests that you upgraded from a pre 2.50.x release of JTAlert. Is that the case? If so what version were you running before the 2.50.3 install?

de Laurie VK3AMA



locked Re: .NET v 5.0.8 x64

HamApps Support (VK3AMA)
 

On 14/07/2021 8:06 am, Stephen Taylor - K6SJT wrote:
FYI - Today's Microsoft Patch Tuesday updates included:

2021-07   .NET 5.0.8  x64 Client   KB5004698

Implemented all of today's Microsoft updates with no negative operational issues experienced using latest versions of WSJT-X and JTAlert.

Stephen Taylor - K6SJT

Tnx Stephen.

JTAlert is working correctly with 5.0.8. Tested with both x64 & x86 installs.

de Laurie VK3AMA


locked Problems with JTAlert latest install

Jim Wysocki
 

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


1761 - 1780 of 37769