Topics

locked Long logging time


John Holmes W9ILY
 

I have logging implemented and have noticed that a long time (about 70 seconds after I click on OK to log the contact) passes before the contact is successfully logged. During this time the display of received signals is not working and, if I work another station during this period I receive an error message about there being a conflict with the logging of the contact. My QSO log file is very big and this may be causing the problem. Are there any suggestions for a work-around?
John  W9ILY.


HamApps Support (VK3AMA)
 

On 22/01/2020 3:15 am, John Holmes W9ILY wrote:
I have logging implemented and have noticed that a long time (about 70 seconds after I click on OK to log the contact) passes before the contact is successfully logged. During this time the display of received signals is not working and, if I work another station during this period I receive an error message about there being a conflict with the logging of the contact. My QSO log file is very big and this may be causing the problem. Are there any suggestions for a work-around?
John  W9ILY.

John,

You forgot to mention the actual logger your using with JTAlert. Also, how big is very big, how many QSOs are in the log.

de Laurie VK3AMA


John Holmes W9ILY
 

Hi Laurie.
Sorry I forgot to note that my log has 214,700 QSOs, 75,075 Kb, WSJT-X
v2.1.2 and JTAlert 2.15.7

John W9ILY


Michael Black
 

But what logger are you using?

de Mike W9MDB




On Wednesday, January 22, 2020, 10:18:41 AM CST, John Holmes W9ILY <w9ily@...> wrote:


Hi Laurie.
Sorry I forgot to note that my log has 214,700 QSOs, 75,075 Kb, WSJT-X
v2.1.2 and JTAlert 2.15.7

John W9ILY






Charlie Hoffman
 

I am also having the same experience with long log times.
This delay began a few releases a go, probably about the same time as you changed to using .NET
Prior to that change, my logging was almost instantaneous.

Sometimes, I get no logging at all to QRZ and need to close JTALERT and start it again.
Even when it fails to post contacts into the QRZ log, it usually logs into my local and on-line HRDlog.

I have always had my logging set up to log to eQSL, HRDLog, and QRZ.

Many times, I now miss two or three cycles, especially when using FT4.

I have been able to slightly improve response by changing XML lookup from QRZ to NONE but don't know if that interacts with the logging or not.

I attempted to go back to an earlier version, before .NET but lost many features such as TEXTING underline.

I'm running  a Windows 10 laptop with an Intel i7-6500U CPU @ 2.5 GHz, *GB RAM.
I run HRD, WSJT-X, JTALERT, and Firefox with QRZ.COM and HRDLOG.net

Do I need a more powerful computer or should I just go back to an older version and forget the latest features?




HamApps Support (VK3AMA)
 

On 23/01/2020 3:18 am, John Holmes W9ILY wrote:
Sorry I forgot to note that my log has 214,700 QSOs, 75,075 Kb, WSJT-X
v2.1.2 and JTAlert 2.15.7

John W9ILY
What Logger are you using with JTAlert?

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 23/01/2020 6:34 am, Charlie Hoffman wrote:
I am also having the same experience with long log times.
This delay began a few releases a go, probably about the same time as you changed to using .NET
Prior to that change, my logging was almost instantaneous.

Sometimes, I get no logging at all to QRZ and need to close JTALERT and start it again.
Even when it fails to post contacts into the QRZ log, it usually logs into my local and on-line HRDlog.

I have always had my logging set up to log to eQSL, HRDLog, and QRZ.

Many times, I now miss two or three cycles, especially when using FT4.

I have been able to slightly improve response by changing XML lookup from QRZ to NONE but don't know if that interacts with the logging or not.

I attempted to go back to an earlier version, before .NET but lost many features such as TEXTING underline.

I'm running  a Windows 10 laptop with an Intel i7-6500U CPU @ 2.5 GHz, *GB RAM.
I run HRD, WSJT-X, JTALERT, and Firefox with QRZ.COM and HRDLOG.net

Do I need a more powerful computer or should I just go back to an older version and forget the latest features?

I doubt you need a new PC.

Everything you described is Internet based.
I have no control over how long QRZ takes to update its log after an upload. I suspect the all the online log services don't log in real-time, but batch update causing delays in the QSOs appearing in your online log.

If logging is working to HRDlog but fails for QRZ, then the likely causes are QRZ itself or your Internet connection is slow. What sort of Internet connection are you using? Perhaps it is intermittent or slow and the uploads are timing out.

de Laurie VK3AMA


John Holmes W9ILY
 

Laurie et al,
I am using DX4WIN but not directly logging to it. I produce a full ADI log
in DX4WIN, then in JTAlert I browse to that file and choose it as my log
file. There is nothing external happening for JTAlert. I do this so I will
have my entire log scanned and new countries, etc. will be alerted. I update
this Full log every few days in DX4WIN and choose the newly created full
file in JTAlert. Is this not correct?

John W9ILY


HamApps Support (VK3AMA)
 

On 23/01/2020 7:13 am, John Holmes W9ILY wrote:
Laurie et al,
I am using DX4WIN but not directly logging to it. I produce a full ADI log
in DX4WIN, then in JTAlert I browse to that file and choose it as my log
file. There is nothing external happening for JTAlert. I do this so I will
have my entire log scanned and new countries, etc. will be alerted. I update
this Full log every few days in DX4WIN and choose the newly created full
file in JTAlert. Is this not correct?

John W9ILY
OK John,

Your using ADIF logging. Of all the loggers supported, that should be the fastest in writing the new QSO to the log file, its a simple file append command.

In your original message you said
I have logging implemented and have noticed that a long time (about 70 seconds after I click on OK to log the contact) passes before the contact is successfully logged.

How are you determining it is taking 70 seconds to update your adif file?

What is the reported size or your adif file?

de Laurie VK3AMA


Michael Black
 

One thing to check is if you can exclude that file/directory from your antivirus antimalware scanning.

de Mike W9MDB



On Wednesday, January 22, 2020, 03:56:54 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 23/01/2020 7:13 am, John Holmes W9ILY wrote:
Laurie et al,
I am using DX4WIN but not directly logging to it. I produce a full ADI log
in DX4WIN, then in JTAlert I browse to that file and choose it as my log
file. There is nothing external happening for JTAlert. I do this so I will
have my entire log scanned and new countries, etc. will be alerted. I update
this Full log every few days in DX4WIN and choose the newly created full
file in JTAlert. Is this not correct?

John W9ILY
OK John,

Your using ADIF logging. Of all the loggers supported, that should be the fastest in writing the new QSO to the log file, its a simple file append command.

In your original message you said
I have logging implemented and have noticed that a long time (about 70 seconds after I click on OK to log the contact) passes before the contact is successfully logged.

How are you determining it is taking 70 seconds to update your adif file?

What is the reported size or your adif file?

de Laurie VK3AMA


John Holmes W9ILY
 

Laurie,
My ADIF file is now 75,077 Kb and the time between when I click on "log this
QSO" to when the notice that the QSO was logged is 64 seconds timed with a
stopwatch. Also, there are more than 4 decoding passes in WSJT-X and the
beginning of a 5th before the notice pops up that the "QSO was logged" and
the decoded calls begin to appear in JTAlert again.
I have excluded JTAlert from my anti-virus scan as suggested.

John W9ILY


HamApps Support (VK3AMA)
 

On 23/01/2020 3:22 pm, John Holmes W9ILY wrote:
My ADIF file is now 75,077 Kb and the time between when I click on "log this
QSO" to when the notice that the QSO was logged is 64 seconds timed with a
stopwatch. Also, there are more than 4 decoding passes in WSJT-X and the
beginning of a 5th before the notice pops up that the "QSO was logged" and
the decoded calls begin to appear in JTAlert again.
I have excluded JTAlert from my anti-virus scan as suggested.

John W9ILY
John,

I think I know what might be happening. Please send me your adif file (zipped up) so I can try and reproduce what your experiencing.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 23/01/2020 3:22 pm, John Holmes W9ILY wrote:
My ADIF file is now 75,077 Kb and the time between when I click on "log this
QSO" to when the notice that the QSO was logged is 64 seconds timed with a
stopwatch. Also, there are more than 4 decoding passes in WSJT-X and the
beginning of a 5th before the notice pops up that the "QSO was logged" and
the decoded calls begin to appear in JTAlert again.
I have excluded JTAlert from my anti-virus scan as suggested.

John W9ILY
John,

I have classified this long QSO confirmation time as a defect.

New code has significantly reduced the time taken to confirm the QSO was written to the adif file.

Check your email, I have sent a new JTAlert build for you to test.

de Laurie VK3AMA
 


Charlie Hoffman
 

I turned off the logging to eQSL and that (almost) eliminated all my delays.
I'm now only logging to QRZ and HRDLog instantaneously and will send my logs to eQSL and LOTW as a batch at the end of my sessions.

Now I get an occasional delay and it appears that QRZ is causing the issue, not the internet, JTA software, or CPU speed.

BTW, I have 100 Mb internet with Spectrum.

TU
Charlie WD4CNO