On 15/09/2020 3:52 am, JoAnn Donaldson
via groups.io wrote:
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
Sorry, buy your wrong on so many fronts.
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.