locked JTAlert 2.50.1 does not receive from WSJT-X - Callsigns, Activity and Band heat windows don't open


Frode Igland
 

Running WSJT-X 2.3.1 and just downloaded JTAlert 2.50.1, but JTAlert does not receive decodes from WSJT-X. Everything worked fine with v2.50.0.

I am not able to open the Callsigns window, not the Activity and Band heat windows. The Decodes window opens but contains nothing.

The title bar of the Main JTAlert window shows reads the JTA version data, my call sign, my log book, etc. but it does not contain band or mode data, reading "[???m,,HRD6+,#1]".

After a rather long while I receive an error message telling that JTALert don't communicate with WSJT-X: 

Unable to communicate with the WSJT-X process.
  UDP Port : 2237
  IP Address : 127.0.0.1
  Values read from WSJT-X config file...
    C:\Users\fi\AppData\Local\WSJT-X\WSJT-X.ini
 
WSJT-X Detected Instance...
  Process Window Title : WSJT-X   v2.3.1   by K1JT, G4WJS, and K9AN
  Process Command Line : "C:\WSJT\wsjtx-2.3.1\bin\wsjtx.exe"
 
Decode alerts and logging will be unavailable until corrected.

As far as I can see the UDP settings and the WSJT-X program location are correct. The UDP settings have not changed since they were orignally set when I installed JTAlert several years and many versions ago.

Any ideas?

73 Frode LA6VQ


HamApps Support (VK3AMA)
 

On 1/05/2021 8:04 am, Frode Igland wrote:
Running WSJT-X 2.3.1 and just downloaded JTAlert 2.50.1, but JTAlert does not receive decodes from WSJT-X. Everything worked fine with v2.50.0.

I am not able to open the Callsigns window, not the Activity and Band heat windows. The Decodes window opens but contains nothing.

The title bar of the Main JTAlert window shows reads the JTA version data, my call sign, my log book, etc. but it does not contain band or mode data, reading "[???m,,HRD6+,#1]".

After a rather long while I receive an error message telling that JTALert don't communicate with WSJT-X: 

Unable to communicate with the WSJT-X process.
  UDP Port : 2237
  IP Address : 127.0.0.1
  Values read from WSJT-X config file...
    C:\Users\fi\AppData\Local\WSJT-X\WSJT-X.ini
 
WSJT-X Detected Instance...
  Process Window Title : WSJT-X   v2.3.1   by K1JT, G4WJS, and K9AN
  Process Command Line : "C:\WSJT\wsjtx-2.3.1\bin\wsjtx.exe"
 
Decode alerts and logging will be unavailable until corrected.

As far as I can see the UDP settings and the WSJT-X program location are correct. The UDP settings have not changed since they were orignally set when I installed JTAlert several years and many versions ago.

Any ideas?

73 Frode LA6VQ
_._,_._,_

Check your PC Protection software. It is likely interfering with  the JTAlertV2.Manager.exe process.

All WSJT-X UDP traffic comes via the Manager process.
The Callsigns, Activity & Band Heat windows are all controlled by the Manager process.

Either JTAlertV2.Manager.exe is not running (check taskmanager) or the UDP traffic between the main JTAlert window and the Manager are being blocked.

Open the Help -> About window (from the main JTAlert window) and copy the "Current operating state" section, copy the content to the clipboard and paste it into a message to this group so I can have a look.

de Laurie VK3AMA


Joe Subich, W4TV
 

As far as I can see the UDP settings and the WSJT-X program location are correct.
Enable Multicast UDP. See the "WSJT-X UDP Setup" section of the JTAlert
(Main) Help file.

It is likely that HRD is capturing the UDP port and preventing UDP
messages from reaching JT-Alert from WSJTX.

73,

... Joe, W4TV


On 2021-04-30 6:04 PM, Frode Igland wrote:
Running WSJT-X 2.3.1 and just downloaded JTAlert 2.50.1, but JTAlert does not receive decodes from WSJT-X. Everything worked fine with v2.50.0.
I am not able to open the Callsigns window, not the Activity and Band heat windows. The Decodes window opens but contains nothing.
The title bar of the Main JTAlert window shows reads the JTA version data, my call sign, my log book, etc. but it does not contain band or mode data, reading "[ ???m,, HRD6+,#1]".
After a rather long while I receive an error message telling that JTALert don't communicate with WSJT-X:
Unable to communicate with the WSJT-X process.
UDP Port : 2237
IP Address : 127.0.0.1
Values read from WSJT-X config file...
C:\Users\fi\AppData\Local\WSJT-X\WSJT-X.ini
WSJT-X Detected Instance...
Process Window Title : WSJT-X v2.3.1 by K1JT, G4WJS, and K9AN
Process Command Line : "C:\WSJT\wsjtx-2.3.1\bin\wsjtx.exe"
Decode alerts and logging will be unavailable until corrected.
As far as I can see the UDP settings and the WSJT-X program location are correct. The UDP settings have not changed since they were orignally set when I installed JTAlert several years and many versions ago.
Any ideas?
73 Frode LA6VQ


Frode Igland
 

Thanks for the  swift response from Laurie and Joe, W4TV.

The JTAlertV2.Manager was not running (not listed in the Task Manager). The only JTAlert part seen in the Task Manager was "Audio & Visual Alerts for WSJT-X". 

There was nothing in the security software indicating that UDP communication between WSJT-X and JTAlert had been prevented (and it has never happenee before, and no other software updates happened between v2.50.0 working well and v2.50.1 not working).

It was not possbile to open the "About JTAlert" to see or copy the "Current operating state"
Changing to Multicast in WSJT-X and JTAlert, or going back to monocast, made no difference.

I then uninstalled JTAlert 2.50.1, power cycled the PC, downloaded and installed JTAlert 2.50.1 again, started the software and this time JTAlertV2.Manager appeared in the Task Manager. The title of the main JTALert window showed band and mode, and everything looked good. Not so.

The Callsign window does not appear, or rather: a miniature of the Callsign window appears when I flip through the windows with Alt-Tab, but it is empty and remains empty (the miniatures have live update) through the WSJT-X decodes, so it doesn't seem to receive the decodes from WSJT-X. Neither the View menu or F3 opens the Callsigns window.

When I try to open the Callsigns window, a JTAlert icon appears on the Taskbar, named Callsigns when I move the cursor over it (Sometimes it also says "(not responding)"). However, when I click on this new icon in the Taskbar to try to maximise the Callsigns window, the pop-up window shows "JTAlertV2.Manager", and the Properties of that does not seem to offer any opportunity to maximise any window. For all I know "JTAlertV2.Manager" mau be another name for the Callsigns window, but I don't thnik so, and I don't understand why that window appears when I try to open the Callsigns window.

The Decodes window opens and shows decodes, but it repeats loading the new and older decodes in no particular order, certainly not time, alphabet or audio frequency. This happens every few seconds. Multicast or monocast makes no difference. After a while the Decodes window stops showing new decodes. After a restart of JTAlert it starts again, still mixing old and new decodes in no particular order, but gradually it falls behind, with the most recent decodes being 2-4 minutes old.

When clicking a new call to work in WSJT-X, the call sign in the main JTAlert window does not switch to the new call sign until I have completed at least 2-3 TX sessions with the new call sign. In one particular instance, the call sign was updated 4.5 minutes after I first called the station.

When I change band in WSJT-X, the title bar in the JTAlert main window toggles the old and the new band. A station that I have worked is toggled between "QSO B4" and "New Band". When I click on a new station in the new band, the look up information of the previous and the new stations toogles with the band, whilst the old call sign remains in place. After a while the call sign changes, but the toggling between the bands and the lookup information continues. After a change from 30 m to 20 m and on to 17 m, all three bands were involved in the toggling of bands, lookup info and "QSO B4" and "New Band" and "First QSO". A further move to 15 m, added 15 m and the
lookup info for the 15 m station in the toggle dance. There may be several toggles per second or up to a few seconds between them.

The band information in the title of the miniature Callsigns window follows the toggling in the JTAlert window, so they are connected.

As I have followed the recommendation to move to Multicast, I also tried running JTAlert and GridTracker (which I very rarely use due to its heavy load on PSK Reporter) simultaneously. GridTracker seemed to receive and show the decodes from WSJT-X  without problems, so the issues at hand seem to lie with JTAlert and the communication with WSJT-X.

Many strange things are happening here, which is a new experience as the WSJT-X/JTAlert combination has always been working well for me up to and including v2.50.0 yesterday before updating to v2.50.1. So I hope the information above can be helpful in understanding what is not set or working correctly.

Just as I was about to hit the Send button a new message popped up:
Heading: "AutoIt Error"
Message text: "Line 39146 (File "C:\Program Files(x86)\HAmApps\JTalert.exe"):Error: Array variable has incorrect number of subscripts or
subscript dimension range exceeded."

Clicking OK, closed JTAlert, but not JTAlertV2.Manager..

Reopening JTAlert everything looks like before.

73, Frode LA6VQ


HamApps Support (VK3AMA)
 

On 1/05/2021 11:30 pm, Frode Igland wrote:
The JTAlertV2.Manager was not running (not listed in the Task Manager). The only JTAlert part seen in the Task Manager was "Audio & Visual Alerts for WSJT-X". 


If JTAlertV2.Manager.exe is not running than most JTAlert functionality will not work, like opening windows and receiving decodes from WSJT-X. AutoIT errors will also be shown if the Manager is not running.

Two reasons why the Manager is not running
  1. Your PC Protection software is interfering and not allowing it to run.
  2. The .NET Desktop Runtime is not correct (x86 or x64) for the version of JTAlert and Windows. You should get an explicit .NET warning if that is the case.

I suggest installing 2.50.0 and see if that works, if it does, that is very good evidence that your protection software is the cause of 2.50.1 not working.


de Laurie VK3AMA


Frode Igland
 

As explained in my message yesterday, after the uninstall and second installation JTAlertV2.Manager was running all the time. 
The NET installation is the same as for v2.50.0, which worked well. Still, all the other things explained in my message yesterday started to act funny. 

No warnings were seen neither for firewall nor virus protection. Is there any reason that the protection software should create problems for v2.50.1 when v2.50.0 ran smoothly? Would any of the changes in v2.50.1 influence the behaviour of the protection software?

73, Frode LA6VQ


Frode Igland
 

As per Laurie's advice I have now uninstalled v2.50.1 and reinstalled v2.50.0, running multicast in WSJT-X and JTAlert. Upon the install, the Firewall was explicitly opened.

The result for v2.50.0 are identical to the results for v2.50.1, described in my lengthy message yesterday, among others:
  • No Callsigns window
  • Decodes window in disarray
  • In the main JTAlert window:
    • Very slow update of the new call sign (2 TX periods or more) and its lookup information,
    • Toogling of the lookup information of recently used call signs, bands, including worked status (First, New Band, QSO B4), whilst the "main" call sign remains unchanged.
  • Band heat and Activity windows opens and looks OK.
I have also installed both version of JTALert at the same time (in very different locations), and have swapped between them without closing down WSJT. I have not run the two versions at the same time. The same issues appear

As per Laurie's request, I have copied the "Current operating state" for both versions  in the attached file, for further review. The only thing I notice is under "UDP Ports used", no port numbers are mentioned for "JTAlertV2.Decodes.exe", but for all I know this may be perfectly OK.

73, Frode LA6VQ


søn. 2. mai 2021 kl. 09:24 skrev Frode Igland <frodeigland2@...>:

As explained in my message yesterday, after the uninstall and second installation JTAlertV2.Manager was running all the time. 
The NET installation is the same as for v2.50.0, which worked well. Still, all the other things explained in my message yesterday started to act funny. 

No warnings were seen neither for firewall nor virus protection. Is there any reason that the protection software should create problems for v2.50.1 when v2.50.0 ran smoothly? Would any of the changes in v2.50.1 influence the behaviour of the protection software?

73, Frode LA6VQ


HamApps Support (VK3AMA)
 

On 3/05/2021 12:02 am, Frode Igland wrote:
I have also installed both version of JTALert at the same time (in very different locations), and have swapped between them without closing down WSJT. I have not run the two versions at the same time. The same issues appear

As per Laurie's request, I have copied the "Current operating state" for both versions  in the attached file, for further review. The only thing I notice is under "UDP Ports used", no port numbers are mentioned for "JTAlertV2.Decodes.exe", but for all I know this may be perfectly OK.

73, Frode LA6VQ

Your JTAlert->About status looks fine. Much of that content wouldn't be present if the Manager process was not running.

I don't know how you managed to install two different copies of JTAlert. That is not supported. Whenever you install a copy of JTAlert, regardless of version, your old JTAlert install is either completely removed or some files removed, either way your old install will be compromised.

I suggest you uninstall all your versions of JTAlert and manually delete the install folders to ensure that any old incompatible files are removed. If you can't remove a folder due to files held open (which could explain the weird behavior your observing) restart your PC then proceed to remove the folders. Don't delete anything under your %localappdata% directory tree else you will loose your settings. Once the old JTAlert installations are removed, install 2.50.1 only.

Once 2.50.1 is installed and running, even if you can't get all the windows to open, wait 3 minutes then use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA


Frode Igland
 

I am sorry for my slow response in a very busy period. I now reply to Laurie's reply in Digest #1460 dated 3 May 2021.

The only thing I did to have v2.50.0 and v2.50.1 installed at the same time, was to install v.2.50.1 in a folder under Program Files, whilst v2.50.0 was installed under Program Files (x86). When opening v2.50.1 I had to select to use  JTAlert with WSJT-X, with JTDX as the alternative. When I first installed v2.50.1, I made a standard installation with default settings, installing it in the Program Files (x86)/Hamapps folder, so the double installation was a very special case just to see if I could notice any differences between the versions, which I didn't.

I followed Laurie's advice to uninstall both versions. All files were deleted by the uninstall, but some folders stuck, so I deleted the remaining folders, as well, leaving no trace of Hamapps or JTALert in the Program Files or the Program Files (x86) folders. The settings under Localappdata were kept. I then made a new installation of JTAlert v2.50.1 with default settings, opened JTAlert v2.50.1,  scanned the logbook to have everything updated. 

The Callsigns window and the Decodes window opened, but regrettably they were just as chaotic as before.

I attach an example with 7 decodes in the WSJT-X Band Activity window, whilst the Callsigns window produced 75 call signs in no particular order, some of which are repetitions from the latest decoded period, whilst others are decoded call signs from random previous periods (identified by different SNR for the same call sign). The Decodes window shows the same lack of order and system, listing old and new decodes in no particlular order.

However, what is listed last in the Callsigns window is listed on the top of the Decodes list, so between the windows the call sign sequence is identical, but it is not linked to the sequence in what has been received form WSJT-X.

The lack of consistency between the latest WSJT-X decodes and JTAlert 2.50.1 makes the Callsigns and Decodes windows useless for selecting calls to work, as the stations.

Everything worked without problems with JTAlert 2.50.0. The problem appeared when I installed v2.50.1, and going back to v2.50.0 did not correct the issue.

The configuration and latest session files have been sent by separate e-mail.

Frode, LA6VQ


Frode Igland
 

UPDATE. ALL OK with v 2.50.1 NOW. 😊
I have now uninstalled JTAlert for the n-th time. Further, I manually cleaned out everything anywhere in the PC named JTalert or HamApps something , including everything in AppData/Local (configuration, logs, session data, etc.). 

Then I power cycled the PC, downloaded and installed JTAlert v2.50.1 and now everything loooks OK. Only the call signs from the latest decoding sequence appear in the Callsigns window and they arrive fast and in an orderly fashion identical to the sequence in the WSJT-X Band Activity window.. The same applies to the Decodes window, with the latest decodes arriving on top of the list.

All is well with v2.50.1. However, I still wonder what in v2.50.1 caused the problems where the Callsigns and Decodes windows showed old and new decodes and repetitions of same in a completely random order and way before and after the end of the decoding sequence.

73, Frode LA6VQ

fre. 14. mai 2021 kl. 13:49 skrev Frode Igland <frodeigland2@...>:

I am sorry for my slow response in a very busy period. I now reply to Laurie's reply in Digest #1460 dated 3 May 2021.

The only thing I did to have v2.50.0 and v2.50.1 installed at the same time, was to install v.2.50.1 in a folder under Program Files, whilst v2.50.0 was installed under Program Files (x86). When opening v2.50.1 I had to select to use  JTAlert with WSJT-X, with JTDX as the alternative. When I first installed v2.50.1, I made a standard installation with default settings, installing it in the Program Files (x86)/Hamapps folder, so the double installation was a very special case just to see if I could notice any differences between the versions, which I didn't.

I followed Laurie's advice to uninstall both versions. All files were deleted by the uninstall, but some folders stuck, so I deleted the remaining folders, as well, leaving no trace of Hamapps or JTALert in the Program Files or the Program Files (x86) folders. The settings under Localappdata were kept. I then made a new installation of JTAlert v2.50.1 with default settings, opened JTAlert v2.50.1,  scanned the logbook to have everything updated. 

The Callsigns window and the Decodes window opened, but regrettably they were just as chaotic as before.

I attach an example with 7 decodes in the WSJT-X Band Activity window, whilst the Callsigns window produced 75 call signs in no particular order, some of which are repetitions from the latest decoded period, whilst others are decoded call signs from random previous periods (identified by different SNR for the same call sign). The Decodes window shows the same lack of order and system, listing old and new decodes in no particlular order.

However, what is listed last in the Callsigns window is listed on the top of the Decodes list, so between the windows the call sign sequence is identical, but it is not linked to the sequence in what has been received form WSJT-X.

The lack of consistency between the latest WSJT-X decodes and JTAlert 2.50.1 makes the Callsigns and Decodes windows useless for selecting calls to work, as the stations.

Everything worked without problems with JTAlert 2.50.0. The problem appeared when I installed v2.50.1, and going back to v2.50.0 did not correct the issue.

The configuration and latest session files have been sent by separate e-mail.

Frode, LA6VQ


HamApps Support (VK3AMA)
 

On 17/05/2021 12:01 am, Frode Igland wrote:
UPDATE. ALL OK with v 2.50.1 NOW. 😊
I have now uninstalled JTAlert for the n-th time. Further, I manually cleaned out everything anywhere in the PC named JTalert or HamApps something , including everything in AppData/Local (configuration, logs, session data, etc.). 

Then I power cycled the PC, downloaded and installed JTAlert v2.50.1 and now everything loooks OK. Only the call signs from the latest decoding sequence appear in the Callsigns window and they arrive fast and in an orderly fashion identical to the sequence in the WSJT-X Band Activity window.. The same applies to the Decodes window, with the latest decodes arriving on top of the list.

All is well with v2.50.1. However, I still wonder what in v2.50.1 caused the problems where the Callsigns and Decodes windows showed old and new decodes and repetitions of same in a completely random order and way before and after the end of the decoding sequence.

73, Frode LA6VQ

Frode,

Did you see my reply to your support request?

The problem with the repeating decodes was due to an incorrect setting. You had the WSJT-X UDP resend  enabled and sending to the same port that JTAlert is receiving decodes from WSJT-X. So JTAlert was re-sending received decodes back to the input and reprocessing those again, stuck in an endless loop. If you need to use the resend feature for some other application, change the port, don't use 2237. This is from your JTAlert config, the parts in red are my comments.
   

BTW, All the uninstalling could have been avoided by simply deleting the JTAlert config file. The default for new configs is not to have that setting enabled and the port set to 2334. So at some time you must have enabled that setting and changed the port.

de Laurie VK3AMA



Frode Igland
 

My apologies for a late reply and thanks for pointing me to the incorrect UDP setting. I have no recollection of checking it, nor changing the port number, but obviously I must have done so. The good thing is that it works just fine now. Thanks again.

73, Frode LA6VQ 


Jim Denneny
 

Known issue. I updated NET to later version.  It works

Jim K7EG


Frode Igland
 

Good.
At my end it did not work even if I had the most recent NET version installed. Now JTAlert works as it should with the very same NET version, and I have no idea why it suddenly chose to work.

73, Frode LA6VQ