toggle quoted messageShow quoted text
I am experiencing a similar 'lock-up' that takes up to 1-minute and 45-seconds
for the DXKeeper logging operation to release WSJT-X FT8 to begin decoding again.
Almost seems like it it tied to the 15-second RX/TX cycles of FT8.
On 30/01/2021 1:00 am, Barry Mcdonald
I have JTAlert
sending to HRD logbook. Use to work great but started locking up
for a few minutes after QSO sent or clicking on anything to
transmit. Kept getting worse. Trouble shot to JTAlert not able
to get existing info from logbook such as B4. After finally
narrowing it down to this I created a new DB in HRD and this
worked great. Unfortunately This has no B4 info. I currently
have 4700 entries in HRD. Is there a limit or solution? If I
remove about half of these it is fine. All software is current.
Let me guess, you're using an Access type Log in HRD, is that
4700 entries is small and is not the cause of your problems. In
the past I have tested with Access logs of over 100,000 entries
In recent months there have been a not insignificant number of
JTAlert/HRD users who have experienced a range of issues, the most
common being increasing slowdowns. The solution in all cases was
to create a new logbook in HRDLogbook, import your old QSOs into
that new Log and then set JTAlert to use that new Log.
You have already created the new log, but have not performed the
import of your old QSOs and that is why the B4's are not working.
Your old QSO and the number of are not the problem so it is safe
to import them into your new Log.
The root cause of the HRD Access log problem is unknown, I suspect
something gets broken within the ODBC DSN that all HRD logs use,
possibly due to Windows updates. Creating a new Log creates a new
DSN after which the problems disappear.
Let us no how you get on.
de Laurie VK3AMA