Brad, I am not seeing that here. I just spent 10 minutes starting at Process Explorer, with a refresh time of 0.5sec, and didn't see the journal file ever. There is

Brad, Don't go back to 2.16.6, 2.16.7 is better as it has a fix for loss of early first pass decodes of WSJT-X 2.2.1 You don't have to do anything special when downgrading, just run the Setup

Thanks Laurie. You nailed it. Trying audio State alerts, the first one is clipped, then all others are fine as long as I test one after another. I had swapped out a monitor and that's when the

I have a CMD file that will copy the current CONFIG file to a directory below the location on the active CONFIG file The backup also has an added feature that it will save it as

Also, in process explorer, it shows two of the sqlite.journal processes at times. Brad, N4PYI

Laurie, I added the exclusions for all of the JT Alert folders and then disabled anti-virus altogether and restarted JT Alert. After one pass with the decodes window open, it decoded the first pass

%localappdata%\HamApps\YOUR_CALLSIGN\config\JTAlertX\config.sqlite de Laurie VK3AMA

I have my JTAlert configured and would like to save a copy of my configuration to give to my daughter and son-in-law so that their config looks like mine. Is there a file that has that info? Not my

Mike, I am reluctant for a couple of reasons An online lookup would need to go into the JTAlertV2.Manager code (that is what is executing your provided

Check the Callsign settings under the "Alerts -> Own Call" section of the Settings. If there is a chance that people will be using the short or the long versions of your callsign when

Laurie....what do you think about doing a QRZ lookup to ensure a callsign is valid before sending out a User Alert? We're getting false decodes and email/text messages about the decode when a QRZ

Got it! Thanks Laurie. C

Brad, You should rarely see the "decodes.sqlite-journal" as it is automatically deleted by the sqlite database engine. AT most you should see brief glimpses of it if you have an

Jesus, With no "JTAlertV2.Manager" UDP port listed in the status shown by the main JTAlert Help->About window, then very likely either JTAlertV2.Manager is not running or the

FYI, The JTAlert "Scan Log" operation considers your Log to be the definitive source of your QSOs and that is the only source of QSO data examined during the scan. There are no attempts

Auto-refresh of the HRDLogbook after logging via its TCP interface (as used by JTAlert) is controlled by HRD itself, there is nothing JTAlert can do to force the refresh. Either there

HRD 5 logging with JTAlert involves direct writing to the log file (there is no logging API available with the old HRD5) and that has always needed the log to be refreshed manually.

Double logging will likely be happening because HRDLogbook is set to automatically log QSOs direct from WSJTX/JTDX. You can confirm this by examining the 2 log records, one will likely

Laurie, I accidentally found why JTAlert was not working right. JTDX rc151 had unchecked the "Accept UDP Requests" box. Rechecked it and JTAlert is working now. BUT... for some reason, I am getting

No issues with latest versions of everything here... Bill W2CQ