locked Re: Logging failures do not update worked before information

David De Coons

Here’s something to check.
Myfriend was having intermittent issues using a Lenovo i5 laptop. We found his CPU running @ 100% and memory around 70%. A little digging found he had two hardware issues.

1) he was running Win 10 woth only 4 GB ram. Upgraded to 12 GB. CPU still at 100% but memory better.

2) he was using a USB to HDMI adapter plugged into a USB 2.0 port for an external 36” TV as a monitor. This was the bottleneck. The laptop has a mini display port so he replaced the adapter with a mini display port to HDMI cable. CPU now around 30% and memory around 30%.

Last, yesterday he cloned the laptop drive to a solid state drive (they are cheap now here in U.S.). He put the SDD drive in the laptop in place of the original drive. Now everything is running MUCH faster.

For HRD Logbook we converted his log from Access to SQL Lite using MariaDB. With larger logs (mine has 20,000 contacts) it speeds logbook database queries up.

And last comment. For the reply on failed to log QSOs you can click on log QSO in WSJT-X as long as you haven’t started the next QSO. Just remember to check the start time.

Some of the intermittent logging issues may be due to CPU or memory bottlenecks in the PC. Not saying al are due to this but worth checking.

Dave wo2x

On May 12, 2020, at 6:37 AM, g4wjs <bill.8@...> wrote:

On 12/05/2020 07:22, HamApps Support (VK3AMA) wrote:
On 11/05/2020 9:37 pm, g4wjs wrote:

I am using DXKeeper for logging. My delay before checking is set to 8 seconds which is perfectly adequate 99% or more of the time, but occasionally when my machine is particularly busy it trips up. Thanks for the tip on clearing the B4 cache. How about my suggestion of a "Retry" button alongside the "Ok" button on the error message about not confirming the logging success, in my case that would cover all the cases as far as I know, assuming a successful retry that finds the logged QSO goes on to update the worked B4 cache in JTAlert.



Do you have DXKeeper set to auto-upload new QSOs to one or more online-logbooks? If so, that is a likely cause of the occasional extended logging times. That has been experience by JTAlert/DXKeeper users in the past.

Regarding a "Retry" button, that would seem to be the most sensible if it wasn't' for the code I have to work with. All the logging code is in the main JTAlert executable and runs on the UI thread. A Retry will involve a database access and a timeout value (if the lookup was unsuccessful), both of which will block the main thread. I am hesitant to add further blocking code. I will give it some thought.

de Laurie VK3AMA

Hi Laurie,

thanks for that, the online lookups are most probably the issue as I have a WiFi connection in the shack which is a bit QRP. No problem on the issues with implementing a "Retry" button, I had assumed that as the failure message doesn't time out that the required code to retry the logbook lookup was easily accessible, but if that is not the case I fully understand the issues. Since no one else has chipped in with similar requests, I am fine with just clearing the B4 cache when this happens. Normally it is pretty obvious where a station is running a frequency and continues to call after a QSO, I have to be pretty distracted not to notice that I have just worked them.



Join Support@HamApps.groups.io to automatically receive all group messages.