On May 12, 2020 at 12:18 PM Jim N6VH <N6VH@...> wrote:

On 5/11/2020 10:13 PM, HamApps Support (VK3AMA) wrote:

On 12/05/2020 12:11 pm, Joe Subich, W4TV wrote:

Please don't!  CQ is the only one that is associated with a useful award
and should always come first.  I would not even mind if ITU zone were
not displayed at all.

73,

   ... Joe, W4TV

Don't worry Joe there will be no changes.

I have always referred to zone pairs as CQ first ITU second. To me it feels more natural because "C" comes before "I" in the alphabet I am guessing.
 
Referring to the Gold-Standard, DXLab, I note DXView is CQ first, same for DXKeeper and the Capture window. A qucik look at ACLog it is the same. I don't bother checking any other loggers.

de Laurie VK3AMA

 

On May 12, 2020, at 2:01 PM, g4wjs <bill.8@...> wrote:



Dave,

did you read my OP? here's a quote of it:

"it seems that when JTAlert cannot confirm logging of a QSO in the configured logging application it does not update its internal worked before database. Often these logging failures are due to slow updates to the logging application even though the log is eventually updated. Restarting JTAlert does sort it out but until then it is easy to mistakenly work the same station twice."

Note that the problem is not a failure to log QSOs, but a failure by JTAlert to check that the QSO was logged successfully. I'm sure you reply may be of use to others but it does not address the issue being discussed in this thread.

73
Bill
G4WJS.

On 12/05/2020 13:48, David De Coons wrote:

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.

73

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.

73
Bill
G4WJS

Bill,

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.

73
Bill
G4WJS.

--
73
Bill
G4WJS.