Tom, FYI, this has been corrected for the next release (likely in 2 days time). de Laurie VK3AMA

While I said the above about using different logs not being possible, using DXKeeper myQTH IDs will have the same affect as having different diffent (filtered) log for the State Alert. Using DXKeeper,

John, I would appreciate access to your current 225K QSO adif file. While I can create a large file with dummy data for testing, real-world data that is subject to unexpected user/program errors is pr

Previously answered here https://hamapps.groups.io/g/Support/message/31261 In addition, no there is no way to restrict the log scanning for an individual Alert type to a different Log. de Laurie VK3AM

JTAlert does not complete its startup until WSJT-X or JTDX is running, as critical communication settings in JTAlert cannot be set until the settings of WSJT-X/ JTDX are determined. JTAlert needs to b

The signal report can be made visible by enabling the "View -> Show DXCC Names" menu option and setting the following in the Settings Window. Alternatively, just hover your mouse over a Callsign and a

No, you don't need to delete the JTAlert or WSJT-X config files. JTAlert provides for zero-configuration changes, everything is automatic. You don't need to make any changes to WSJT-X unless you want

#Beta

Users who want to test UDP Multicast support provided by the current Beta build of JTAlert can try this build... https://dnl.HamApps.com/Beta/JTAlert.2.16.10.build.0012.Beta.Setup.exe Please report yo

#Announcement

Users who want to test UDP Multicast support provided by the current Beta build of JTAlert can try this build... https://dnl.HamApps.com/Beta/JTAlert.2.16.10.build.0012.Beta.Setup.exe Please report yo

Joe, Try deleting the JTAlert.ini file located at %localappdata%\HamApps de Laurie VK3AMA

Good news! de Laurie VK3AMA

John, FYI, A very near future JTAlert build utilizes a new ADIF file importer that is an improvement over the current importer, which as you know was a significant improvement over the old importer th

Scott, Currently, only DXKeeper can provide what you want. The JTAlert "Rebuild Alert Database" operation (which scans your log) can consider QSOs that have one or more DXKeeper myQTH IDs defined. JTA

This defect has been resolved. Joe WC4R, who experienced and reported this defect, has confirmed the latest JTAlert beta has corrected the problem. The next public release has the fix. The cause was a

Tom, FYI, a quicker solution (without the ability to save the old database) is to temporarily set the Decodes startup options to "Delete All Records" then restart (close & open) the Decodes window. On

See the Settings window... No, the width cannot be changed to 4 callsigns. You can add additional lines. de Laurie VK3AMA

John, "I manually import all of my FT8 ADIF files from WSXT-X and JTDX into that logging program" is the problem. You need to be importing the ADIF file that JTAlert is updating when QSOs are logged a

Tom, You only need to change the enabled state via the "Settings>Alerts" menu. The corresponding checkbox in the Settings window is automatically linked to the main gui menu. Rebuilding the Alert data

Here's my 4 instance data (using Process Explorer). de Laurie VK3AMA

Amos, I am left thinking that the non-normal high CPU usage of JTAlert and the stalling of the program is due to an external influence. Likely your HRD Logbook. Are you using a MSAccess log? In recent