Reading the JTAlert Docs, it mentions that you can adjust the how to adjust the Check QSO Log Record time in JTAlert' but I can not find it under Settings/Manage Settings/Misc. See the two attach files. One shows it. This is from the N3FJP Digital Hits Page and the other which does not show it is from Settings/Manage Settings/MISc. has this setting been removed? I am having problems with JTAlert not confirming contact with my ACLog.

JoAnn - AB8YZ

First some housekeeping. Please don't post cell-phone images they typically end up being excessively large in both physical size and dimensions. A better option is to use the tools provided by Windows to capture an individual window or part of a window, see this pinned topic https://hamapps.groups.io/g/Support/message/20528

If you insist on using cell-phone images, take the time to reduce the size before posting. You current image size of ~4MB at 4096 x 2304 pixels is unnecessarily large. For an image like this, it doesn't need to be any more than ~500px in width with a more manageable less than 100KB file size.

Regarding the timing adjustment setting, it is under the Logging section of the Settings window. Documented under the "Frequently Asked Questions -> Warning about QSO not logged when it is logged" help file topic.

From the Logging section of the Settings...


de Laurie VK3AMA

I do not see any entry for Asjustment under Logging or under Miscellaneous.

Under Miscellaneous I see

        Hot Keys

Thats it. No Entry to adjust the Timing. Under Logging I see

          Last QSO API

          Last B4 Database

          Standard ADIF File

        + DXLAb DXkeeper

        HDR V5/V6

        Log4OM V1

        Log4OM V2

      +ACLog

Click the "Logging" entry in the left tree-view display.
   

de Laurie VK3AMA

I hate to say this but that menu does not exist on my JTALert. Here is what it says on mine.

Seriously!

Your image shows your not even selecting the "Logging" entry as has been advised several times.
You have selected the "Standard ADIF File" entry (blue/white highlight)


Select the "Logging" entry pointed to by the big red arrow.

If you don't get the "Logging" entry highlighted you have not selected it. Like so...


de Laurie VK3AMA

Besides I have already figured out how to solve my problem with JTALert NOT logging to ACLog. It seems that when JTALert does the check for Worked Before that is when ACLog pops the error message and the Log entry is deleted. I turned OFF CHECK BEFORE and now it logs successfully. I never understand why JTALert needed to remind you that you have already worked a station before when WSIT-X already does by turning the contact GREEN.

   I suspect the timing issue is ONLY with the Before Check. I am running ACLog on a separate computer thus have to use the Manual Mode to access ACLog. Also do not understand why JTALert needs a PHYSICAL Path to the database when the N3FJP API gives the Client all the access it needs.

So put this thread asleep. I have found a flaw in how the BeFor Check is done when ACLog is on a separate computer. I found a work around for the flaw. If the Developer wants to correct this, I am more than willing to tests an update.

JoAnn Donaldson - AB8YZ 

• First, there is nothing to fix, there is no B4 flaw to correct.

• What is this error message that ACLog is showing? Post an image of this ACLog generated message.

• WSJT-X reporting of B4 is independent of your ACLog log file and can be grossly out-of-sync with ACLog. JTAlert does its B4 checks against your primary log, ACLog, not the WSJTX log file which at any time could be empty, truncated or missing.
  
  
• The Timing adjustments your referring to have NOTHING to do with B4 checks. It used used purely for the QSO logged success checks. This is why the settings entry is under the "Logging" section (funny that).
  
  
• The ACLog API is very inefficient when performing many Callsign lookups (for the B4 checks) at the end of a busy FT8 period where there may be 20, 30, 40 or more callsigns to check. Direct querying of the Log file is the quickest technique.
  
  
• The ACLog API doesn't allow for custom sql queries that JTAlert uses, so direct log access is needed. This applies to all the supported loggers, not just ACLog.
  
  
• You have slowed things down further by having the ACLog file on a different PC than JTAlert so network latency is introduced further slowing log file reads.  JTAlert does cache (in memory) the results of the slow disk file lookups, but there will always be at least one physical log lookup when a callsign is first decoded.
  
  
• The Alert database (used to determine what alerts a callsigns/decode generates) requires direct access to the Log file in order to run the many hundreds of sql queries needed  to rebuild the database. The Alert database is used for high-speed determination of what alerts are triggered, it is impractical to run multiple queries (if even possible) via the ACLog API to check if a Callsign is a needed DXCC, State, Grid, Prefix, etc, at the end of a FT8 period. This in-memory database is used.
  

If I'm not mistaken you don't get very good caching on a remote network file by default.

Mike

1. When a callsign is FIRST decoded to perform a B4 check for the current Band/Mode.
   
   
2. When confirming a QSO was logged by reading the log. Past bad experiences with other loggers has shown that the status reported by the logger (via its api) after logging may not be correct and cannot be relied upon. HRD was notorious for reporting logging success when the QSO was never logged. Direct reading of the log avoids that.
   
   
3. When performing the Alert database rebuild.

de Laurie VK3AMA

I turned OFF CHECK BEFORE and now it logs successfully.