locked Issue with JTAlert v2.50.4


KI4RFM
 

I am having an issue with JTAlert 2.50.4 where when I click on a callsign in the Callsign Display, nothing happens in WSJT-X. The DX Call field in WSJT-X is neither filled in nor does it jump to that callsign's frequencies and start transmitting. I can open the Decodes Window and click calls and everything works fine.

I'm running Windows 10 Pro 64-Bit v20H2 with .NET Framework v5.0.8 installed on a laptop. I have tested this in both WSJT-X v2.4.0 and v2.5.0-rc3 using multicast address 239.255.0.1 and port 2237. I have all the configuration options set to match the manual. I uninstalled WSJT-X and JTAlert and then deleted all the configuration data. I then installed both program and still had the same issue. I then went to another computer that has never had either program installed. After installing the same versions, JTAlert worked with out issue.

So far on my laptop, I have tried with both the firewall on and off. I have disabled all the anti virus and turned off everything in Windows Defender, still didn't solve the issue. I have tried on both the multicast and 127.0.0.1, same result. It seems that data is going to JTAlert but nothing is coming back from JTAlert to WSJT-X. If I revert back to the previous version I was using, which was 2.16.17, everything works correctly.

I took this a step further and Wiresharked the loopback interface. I can see the packets going out on the multicast address but I never see any packets generated when I click a callsign in the Callsigns Display in JTAlert. I do have WSJT-X UDP multicast on loopback enabled and have no other programs running that would access the multicast data. I also enabled debugging in JTAlert and found a debug file that states that it did recognize that the callsign was clicked.

At this point I am stumped. Has anyone else experienced this issue? I can provide screenshots if it helps.


HamApps Support (VK3AMA)
 

On 26/07/2021 5:48 am, KI4RFM wrote:
I am having an issue with JTAlert 2.50.4 where when I click on a callsign in the Callsign Display, nothing happens in WSJT-X. The DX Call field in WSJT-X is neither filled in nor does it jump to that callsign's frequencies and start transmitting. I can open the Decodes Window and click calls and everything works fine.

I'm running Windows 10 Pro 64-Bit v20H2 with .NET Framework v5.0.8 installed on a laptop. I have tested this in both WSJT-X v2.4.0 and v2.5.0-rc3 using multicast address 239.255.0.1 and port 2237. I have all the configuration options set to match the manual. I uninstalled WSJT-X and JTAlert and then deleted all the configuration data. I then installed both program and still had the same issue. I then went to another computer that has never had either program installed. After installing the same versions, JTAlert worked with out issue.

So far on my laptop, I have tried with both the firewall on and off. I have disabled all the anti virus and turned off everything in Windows Defender, still didn't solve the issue. I have tried on both the multicast and 127.0.0.1, same result. It seems that data is going to JTAlert but nothing is coming back from JTAlert to WSJT-X. If I revert back to the previous version I was using, which was 2.16.17, everything works correctly.

I took this a step further and Wiresharked the loopback interface. I can see the packets going out on the multicast address but I never see any packets generated when I click a callsign in the Callsigns Display in JTAlert. I do have WSJT-X UDP multicast on loopback enabled and have no other programs running that would access the multicast data. I also enabled debugging in JTAlert and found a debug file that states that it did recognize that the callsign was clicked.

At this point I am stumped. Has anyone else experienced this issue? I can provide screenshots if it helps.
_

WSJT-X not responding to JTAlert Callsign click events is a common problem caused by an incomplete WSJT-X UDP Server settings. Specifically, not having the "Accept UDP requests" enabled. Do you have that enabled on the affected WSJT-X installations?

de Laurie VK3AMA


KI4RFM
 

Hi Laurie,

I do have it enabled. Here is my settings.



Thanks.


Laurie, VK3AMA
 

On 26/07/2021 8:59 am, KI4RFM wrote:

I do have it enabled. Here is my settings.
OK.

Since you're clicking Callsigns in JTAlert, that indicates the UDP comms between JTAlert and WSJT-X is working correctly. If the comms was broken than JTAlert would not display callsigns or report the Band and Mode in the titlebar text. With "Accept UDP  requests" enabled the DXCall in WSJT-X should be getting populated with the callsign clicked in JTAlert. One other possibility is that you are running WSJT-X with elevated privileges, set to run as administrator. Check both the shortcut used to start WSJT-X and the wsjtx.exe executable file properties to ensure the "Run as administrator" setting is not enabled.

de Laurie VK3AMA


Laurie, VK3AMA
 

Also, check the Callsigns window Options (click the gear icon) and see what you have set for the "Wsjtx reply" setting. Perhaps you have it set for double-click and have only been using a single click or have it set to disabled.

   

de Laurie VK3AMA


KI4RFM
 

On Sun, Jul 25, 2021 at 07:27 PM, Laurie, VK3AMA wrote:
On 26/07/2021 8:59 am, KI4RFM wrote:
I do have it enabled. Here is my settings.
OK.

Since you're clicking Callsigns in JTAlert, that indicates the UDP comms
between JTAlert and WSJT-X is working correctly. If the comms was broken
than JTAlert would not display callsigns or report the Band and Mode in
the titlebar text. With "Accept UDP  requests" enabled the DXCall in
WSJT-X should be getting populated with the callsign clicked in JTAlert.
One other possibility is that you are running WSJT-X with elevated
privileges, set to run as administrator. Check both the shortcut used to
start WSJT-X and the wsjtx.exe executable file properties to ensure the
"Run as administrator" setting is not enabled.

de Laurie VK3AMA
Hi Laurie,

I checked both the shortcut and the exe for WSJT-X, neither are set to run as administrator. I also check JTAlert and nothing is set to administrator there either.

Thanks


KI4RFM
 

On Sun, Jul 25, 2021 at 07:40 PM, Laurie, VK3AMA wrote:
Also, check the Callsigns window Options (click the gear icon) and see what you have set for the "Wsjtx reply" setting. Perhaps you have it set for double-click and have only been using a single click or have it set to disabled.

   

de Laurie VK3AMA

I have it set to single click. I've tried it with both double click and single click.


HamApps Support (VK3AMA)
 

On 26/07/2021 9:58 am, KI4RFM wrote:
I checked both the shortcut and the exe for WSJT-X, neither are set to run as administrator. I also check JTAlert and nothing is set to administrator there either.


If JTAlert is receiving decodes and band/mode changes from WSJT-X there is no reason for WSJT-X to not be responding to the callsign click events from JTAlert.

I'm sorry to say, but I am out of suggestions except to take a closer look at your Protection software (what are you running?). Some Protections software is notorious for not completely disabling their protecting interference even when the user has disabled the real-time scanning (eg. Norton).

de Laurie VK3AMA


KI4RFM
 

On Sun, Jul 25, 2021 at 08:22 PM, HamApps Support (VK3AMA) wrote:
On 26/07/2021 9:58 am, KI4RFM wrote:
I checked both the shortcut and the exe for WSJT-X, neither are set to run as administrator. I also check JTAlert and nothing is set to administrator there either.


If JTAlert is receiving decodes and band/mode changes from WSJT-X there is no reason for WSJT-X to not be responding to the callsign click events from JTAlert.

I'm sorry to say, but I am out of suggestions except to take a closer look at your Protection software (what are you running?). Some Protections software is notorious for not completely disabling their protecting interference even when the user has disabled the real-time scanning (eg. Norton).

de Laurie VK3AMA

I'm using Comodo Internet Security. I have JTAlert and WSJT-X added excluded but I've tried with it completely disabled and with Windows Defender disabled and still had no success. I use the same version of Comodo on the other computer where the clicks worked.

Appreciate the help on this. I will continue to try to solve this issue as this is my main computer for doing all my FT8 work. I really like this version JTAlert so I want to use it.

Thanks Laurie.


KI4RFM
 

Hey Laurie,

Got it working finally. Just to share what I found in case it was to come up with someone else. I decided to go through all the processes and see if there was one interfering with JTAlert. When I killed the process called ROG GameFirst III Service process, the clicks on the callsigns began working. I disabled the AsusGameFirstService under Services to prevent the process from starting again. I've restarted the laptop several times and so far JTAlert has worked correctly. I've already made several contacts. I will continue to test it this but I believe this issue may be solved.

Appreciate the help on this issue. I'm really liking the new version, especially the option to filter callsigns to other panels. Looking forward to making more contacts.

Thanks again.

de Jacob KI4RFM


Jim Cooper
 

On 25 Jul 2021 at 19:34, KI4RFM wrote:

Just to share what I found in case
it was to come up with someone else.
Excellent ... that's always helpful to everyone,
not just Laurie.

I decided to go through all the
processes and see if there was one
interfering with JTAlert. When I
killed the process called ROG
GameFirst III Service process, the
clicks on the callsigns began working.
THAT is a demonstration of very intelligent
step by step troubleshooting !! That's what
it is all about, with these mysterious problems.

I disabled the AsusGameFirstService
under Services to prevent the process
from starting again. I've restarted
the laptop several times and so far
JTAlert has worked correctly.
If you don't use Asus Games, you might consider
completely removing it using the Control Panel,
Programs ... that way it can't come back and bite
later. Nice work ... not likely that Laurie or anyone
on here could have figured that one out remotely. :))

Jim w2jc


KI4RFM
 

On Sun, Jul 25, 2021 at 10:52 PM, Jim Cooper wrote:
On 25 Jul 2021 at 19:34, KI4RFM wrote:

Just to share what I found in case
it was to come up with someone else.
Excellent ... that's always helpful to everyone,
not just Laurie.

I decided to go through all the
processes and see if there was one
interfering with JTAlert. When I
killed the process called ROG
GameFirst III Service process, the
clicks on the callsigns began working.
THAT is a demonstration of very intelligent
step by step troubleshooting !! That's what
it is all about, with these mysterious problems.

I disabled the AsusGameFirstService
under Services to prevent the process
from starting again. I've restarted
the laptop several times and so far
JTAlert has worked correctly.
If you don't use Asus Games, you might consider
completely removing it using the Control Panel,
Programs ... that way it can't come back and bite
later. Nice work ... not likely that Laurie or anyone
on here could have figured that one out remotely. :))

Jim w2jc
Thanks Jim. Its always good to be able to contribute.

I definitely plan to remove the Asus service. That's on my agenda for tomorrow night.

Laurie has done a great job. I really like the new look and operation. Looking forward to putting it to work.

Hopefully this will help someone else that might run into a similar problem.

73 for now, going to bed.

Thanks
Jacob KI4RFM


KI4RFM
 

Hey Laurie,

Just wanted to let you know that I haven't had anymore issues with JTAlert since removing the Asus GameFirst service. I have it completely uninstalled now so it shouldn't create anymore issues. Turns out it was network traffic optimization tool so that would probably explain why it was causing issues with the UDP connection.

Hopefully this may help out anyone else that has an Asus laptop with this same software.

Thanks
Jacob KI4RFM


HamApps Support (VK3AMA)
 

On 30/07/2021 10:34 am, KI4RFM wrote:
Hey Laurie,

Just wanted to let you know that I haven't had anymore issues with JTAlert since removing the Asus GameFirst service. I have it completely uninstalled now so it shouldn't create anymore issues. Turns out it was network traffic optimization tool so that would probably explain why it was causing issues with the UDP connection.

Hopefully this may help out anyone else that has an Asus laptop with this same software.

Thanks
Jacob KI4RFM

Tnx for the update.

de Laurie VK3AMA