Date   

locked Re: Slow path to logging

HamApps Support (VK3AMA)
 

On 18/02/2021 10:28 am, Radio K0HB wrote:

I ran some experiments, Laurie, and it appears that JTAlert is involved.

 

First, as a benchmark, I took JTAlert offline and logged directly from WSJT-X to Log3OM.

 

From the time I pressed “Log it” until the QSO arrived in Log4OM took a second or two.  This result is consistent.

 

Then I put JTAlert back in the app lineup (with appropriate UDP settings).

 

Then I did 4 experiments, each one twice to check consistency.

 

  1. I turned off the check as per your message below.  Two QSO’s each took about 10 seconds to arrive.
  2. I turned the check back on, with a wait of 5.  Two QSO’s each took about 25 seconds.
  3. Increased the wait to 10.  30 seconds elapsed.
  4. Increased the wait to 20.  About 50 seconds elapsed.

 

So it seems that JTAlert, even without the check, adds some (tolerable) delay.

 

Then, increasing the “time before check” also increases the travel time to Log4OM.

 

For now, I will turn off the check as you recommend, as the delay in that condition is tolerable.

 

73, de Hans, K0HB

 


Hans,

Your comparing Apples to Oranges. WSJT-X -> Log4 direct logging compared to WSJT-X -> JTAlert -> Log4 logging via the Log4OM TCP logging interface which I assume uses a different pipe-line through the Log4 code.

What Log type are you using in Log4OM V2? SQLite or MySQL? How many records does it contain?

If you have JTAlert logging confirmation checks turned off and your getting 10 second delays before the QSO gets written to the log, those delays are coming from Log4OM. Perhaps it is delayed while it does its post logging processing for QSOs logged via its TCP interface only. I don't know, that is speculation.

I would like to see some of the timings that JTAlert records in its debug file to reassure myself that JTAlert is not introducing delays. Please do the following...
  • Enable debug recording via the JTAlert "Settings -> Enable Debug Recording" menu.
  • Restart JTAlert.
  • With the "Do not check or report logging success/failure" checkbox ticked, log a QSO.
  • After the QSO has been logged and appeared in the Log4OM log you can turn off the debug recording.
  • Then use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis. Pleas include a note of the Callsign logged.

de Laurie VK3AMA



locked Re: Slow path to logging

Radio K0HB
 

I ran some experiments, Laurie, and it appears that JTAlert is involved.

 

First, as a benchmark, I took JTAlert offline and logged directly from WSJT-X to Log3OM.

 

From the time I pressed “Log it” until the QSO arrived in Log4OM took a second or two.  This result is consistent.

 

Then I put JTAlert back in the app lineup (with appropriate UDP settings).

 

Then I did 4 experiments, each one twice to check consistency.

 

  1. I turned off the check as per your message below.  Two QSO’s each took about 10 seconds to arrive.
  2. I turned the check back on, with a wait of 5.  Two QSO’s each took about 25 seconds.
  3. Increased the wait to 10.  30 seconds elapsed.
  4. Increased the wait to 20.  About 50 seconds elapsed.

 

So it seems that JTAlert, even without the check, adds some (tolerable) delay.

 

Then, increasing the “time before check” also increases the travel time to Log4OM.

 

For now, I will turn off the check as you recommend, as the delay in that condition is tolerable.

 

73, de Hans, K0HB

 

 

From: HamApps Support (VK3AMA)
Sent: Wednesday, February 17, 2021 22:15
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

On 18/02/2021 7:36 am, Radio K0HB wrote:

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB


Log4OM V2 is very slow (compared to Log4OM V1) for many of its logbook functions.

A 30 second delay in a new QSO appearing in the log is abnormal.

PC Protection software interference would not normally introduce that sort of delay in UDP traffic, at most a few milliseconds.
That sort of delay suggests that Log4OM is busy doing other processes post-logging before it finally writes the QSO to the log file (which is where JTAlert is looking to confirm the QSO is written).

Likely Log4OM is doing online log uploads, an XML lookup and updating its many internal award tracking database tables (my guess the award tracking updates is the most likely cause).

To mitigate Log4OM V2 slow logging, you can turn off JTAlert's logging confirmation check. If you are not seeing QSOs failing to be logged, that is they always appear despite the delays, turning off the QSO logged check is my recommendation. With this setting enabled, JTAlert will treat the logging as successful.



de Laurie VK3AMA

 


locked Re: Sound files for JTAlert ver 2.16.17

Andy k3wyc
 
Edited

Thanks!  After deleting the existing sound files the new set was added and the sound file installed version was changed.

73,
Andy k3wyc


locked Re: New Computer Hookup Problem

HamApps Support (VK3AMA)
 

On 16/02/2021 11:47 am, W7JHR via groups.io wrote:
I just changed computers and when I reloaded the WSJT-x and JTAlert software I noticed two changes.  One, the stations in the alert call window show their states but the dx calls don’t show the countries. Two, when I log the QSO to ACLog it only picks up part of the information.  In the past, it would log state, county, grid etc.  Any thoughts?

Thanks,
Jim W7JHR

If your not seeing country names it will be due to not having the "Show DXCC Names" menu ticked. It is under the "View -> Callsign Display Lines" menu.

If additional log data (like State, Name, QTH, Zones, etc) is not being logged it will be due to the corresponding fields in the JTAlert Log Fields area not containing that data.  That data can come from three places, either a previous QSO in your log, an XML lookup (assuming it is enabled in JTAlert) or by manually entering the data pre-logging.

Enabling an XML service in JTAlert is the recommended method.
Make sure you have the Log Fields visible and watch if the data is getting populated after you change your QSO partner (change the WSJT-X DXCall). The data may take a couple of seconds to populate depending on the speed of your Internet connection or the XML service at the time. If the data is not getting updated from the XML lookup, you likely have  incorrect  credentials set or your subscription has expired.

de Laurie VK3AMA


locked Re: Slow path to logging

HamApps Support (VK3AMA)
 

On 18/02/2021 7:36 am, Radio K0HB wrote:

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB


Log4OM V2 is very slow (compared to Log4OM V1) for many of its logbook functions.

A 30 second delay in a new QSO appearing in the log is abnormal.

PC Protection software interference would not normally introduce that sort of delay in UDP traffic, at most a few milliseconds.
That sort of delay suggests that Log4OM is busy doing other processes post-logging before it finally writes the QSO to the log file (which is where JTAlert is looking to confirm the QSO is written).

Likely Log4OM is doing online log uploads, an XML lookup and updating its many internal award tracking database tables (my guess the award tracking updates is the most likely cause).

To mitigate Log4OM V2 slow logging, you can turn off JTAlert's logging confirmation check. If you are not seeing QSOs failing to be logged, that is they always appear despite the delays, turning off the QSO logged check is my recommendation. With this setting enabled, JTAlert will treat the logging as successful.



de Laurie VK3AMA


locked Re: Sound files for JTAlert ver 2.16.17

HamApps Support (VK3AMA)
 
Edited

On 18/02/2021 7:22 am, Andy k3wyc wrote:
I recently updated JTAlert, callsign database, and sound files to the current versions.  I didn't like the announcement voice and I have made several attempts to use earlier sound file versions.  All attempts to change the sound files to an earlier version have failed.

Is it possible to choose what sound files version is used with JtAlert ver 2.16.17?  Is so, would someone please tell me how to do it.  Sound file versions 2.2.0, 2.5.0, 2.5.1, and 2.5.2 all install without error but all result in ver 2.5.3 being reported as installed and the voice does not change.

Thanks and 73,
Andy, k3wyc

None of the Sound files are tied to a specific version of JTAlert.

The install location for the sound files is %programdata%\HamApps\Sounds
Delete all files in that directory then proceed to installing whatever version of the files you want.

de Laurie VK3AMA



locked Re: Slow path to logging

Michael Black
 

Exclude all of your ham software folders and data locations.
The antivirus programs are interfering with all sorts of ham stuff including logging QSOs

For Windows Defender: https://support.microsoft.com/en-us/help/4028485/windows-10-add-an-exclusion-to-windows-security

For example I exclude all of these
c:\Program Files (x86)\HamApps
c:\ProgramData\HamApps
c:\WSJT
%LOCALAPPDATA%\WSJT-X (and any other WSJT-X directories)
%HOMEPATH%\flrig.files
%HOMEPATH%\fldigi.files

Exclude your logging program and it's data files too.
For Log4OM and Log4OM2 I also have
%LOCALDATA%\LogOM
%APPDATA%\LogOM2

Mike W9MDB


On Wednesday, February 17, 2021, 02:36:22 PM CST, Radio K0HB <kzerohb@...> wrote:


I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB

 

 


locked Re: Slow path to logging

Radio K0HB
 

Interesting.

 

My app versions:

 

Log4OM 2.11.0

WSJT-X 2.3.0

JTAlert 2.16.17

 

My WSJT-X is newer than yours, but this problem pre-dates that upgrade.

 

 

 

Sent from Mail for Windows 10

 

From: Lawrence Godek
Sent: Wednesday, February 17, 2021 20:44
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

I had that same problem using an older version of Log4OM.  Lucky to make and log 2 QSO's in a minute or more.  With 2.11.0.0 logging is almost instantaneous.  I use WSJT 2.2.2 and JTAlert 2.16.17.  Computer is a WIN 7Pro with 16 GB ram and a regular 1 TB HD.  Nice to have quick logging working.

Larry W0OGH

 

On 2/17/2021 1:36 PM, Radio K0HB wrote:

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB

 

 

 


locked Re: Slow path to logging

Lawrence Godek
 

I had that same problem using an older version of Log4OM.  Lucky to make and log 2 QSO's in a minute or more.  With 2.11.0.0 logging is almost instantaneous.  I use WSJT 2.2.2 and JTAlert 2.16.17.  Computer is a WIN 7Pro with 16 GB ram and a regular 1 TB HD.  Nice to have quick logging working.

Larry W0OGH


On 2/17/2021 1:36 PM, Radio K0HB wrote:

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB

 

 


locked Slow path to logging

Radio K0HB
 

I am experiencing what I think is exceptionally long transfer of contact information from WSJT-X to Log4OM via JTAlert.

 

Here’s my setup.  Computer is a very capable I7 windows machine, 16Gig RAM, SSD drive, running Windows 10.

 

Applications are the latest versions of JTAlert, WSJT-X, and Log4om.

 

Running just WSJT-X and Log4OM, the QSO travels from WSJT-X in a second or less.

 

Inserting JTAlert into the mix (with appropriate adjustments to UDP), every contact results in an error box that the contact may not have been logged.  I have adjusted the delay for that complaint out to 30 seconds, but it still happens.

 

Eventually (at around 35 seconds) the contact always DOES show up in Log4OM, suggesting the UDP path is good, but REALLY slow.

 

Any ideas?

 

73, de Hans, K0HB

 

 


locked Sound files for JTAlert ver 2.16.17

Andy k3wyc
 

I recently updated JTAlert, callsign database, and sound files to the current versions.  I didn't like the announcement voice and I have made several attempts to use earlier sound file versions.  All attempts to change the sound files to an earlier version have failed.

Is it possible to choose what sound files version is used with JtAlert ver 2.16.17?  Is so, would someone please tell me how to do it.  Sound file versions 2.2.0, 2.5.0, 2.5.1, and 2.5.2 all install without error but all result in ver 2.5.3 being reported as installed and the voice does not change.

Thanks and 73,
Andy, k3wyc


locked Re: One issue and a couple of suggestions

Carl - WC4H
 

Hi Darryl.

I have the same problem with my 4k monitor.

I changed the resolution to 2560 x 1440 on my Windows and Raspberry Pi 4B.  That helped a lot.

Additionally, on Windows, you can change the Font Size used by Windows.  It might take a little playing around to get it to your taste but it helps a lot.

73.
Carl - WC4H


locked Re: New Computer Hookup Problem

Dave Garber
 

not without seeing the full setup

perhaps you virus program is blocking access to qrz??


Dave Garber
VE3WEJ / VE3IE


On Tue, Feb 16, 2021 at 3:48 PM W7JHR via groups.io <W7JHR=yahoo.com@groups.io> wrote:
Hi Dave,
I have put my correct QRZ login and password in.  Still no joy.  Any thoughts? Very frustrating, I know it’s just a matter getting the settings right.
Thanks,
Jim W7JHR


locked Re: New Computer Hookup Problem

W7JHR@...
 

Hi Dave,
I have put my correct QRZ login and password in.  Still no joy.  Any thoughts? Very frustrating, I know it’s just a matter getting the settings right.
Thanks,
Jim W7JHR


locked Re: New Computer Hookup Problem

Dave Garber
 

Jtalert requires qrz login .  check your user and password are entered and correct


On Mon., Feb. 15, 2021, 7:47 p.m. W7JHR via groups.io, <W7JHR=yahoo.com@groups.io> wrote:
I just changed computers and when I reloaded the WSJT-x and JTAlert software I noticed two changes.  One, the stations in the alert call window show their states but the dx calls don’t show the countries. Two, when I log the QSO to ACLog it only picks up part of the information.  In the past, it would log state, county, grid etc.  Any thoughts?

Thanks,
Jim W7JHR


locked New Computer Hookup Problem

W7JHR@...
 

I just changed computers and when I reloaded the WSJT-x and JTAlert software I noticed two changes.  One, the stations in the alert call window show their states but the dx calls don’t show the countries. Two, when I log the QSO to ACLog it only picks up part of the information.  In the past, it would log state, county, grid etc.  Any thoughts?

Thanks,
Jim W7JHR


locked Re: JTAlert Crash After Viewing Or Changing Settings

David - AK2L
 

Laurie,

After following the "new computer" procedure recommended by you, the problem continued to happen.  As a last resort, I removed JTAlert completely from my computer and did not try to restore previous settings.  I instead went through the various dialogs, changing only a few items at a time, then exiting and re-launching and so on.  The problem still happens.

I like JTAlert so much that I will live with it, but if I can help you diagnose the problem, let me know.  Before starting the last install, while exploring my computer, I did come across some dump files with JTAlert in the name.

AK2L


locked Re: Jtalert not fully updated

Michael Black
 

He needs to contact QRZ and see what's wrong.

I have a secondary callsign and a managed callsign and they both work with the xml query

But his secondary doesn't work even though it's a valid QRZ weg page just like my secondary callsign.



Mike W9MDB


On Monday, February 15, 2021, 12:25:26 AM CST, <asobel@...> wrote:


Lauri

 

4X1UF is a friend of mine. I did warn him about the problem. I did also QSO him many times just to check out if I am heard. What you see below is a QSO of this morning. What’s the connection to B4?

Please explain why the Name and QTH are not displayed.

Usually I regard a callsign that does not display name or QTH as a pirate or a WSJT-X phony call and check him on QRZ. Are there other cases of none display?

 

Amos 4X4MF

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Monday, February 15, 2021 7:48 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Jtalert not fully updated

 

On 15/02/2021 3:58 pm, asobel@... wrote:

Laurie

 

This is the problem:

Amos 4X4MF


That looks correct. What's the problem? If it is the lack of a Name & QTH, that would be due to those fields not containing data in the previous QSO in your Log (where the B4 is coming from). If it was a new QSO and not a B4, the result would be the same as the QRZ XML returns the following...

<QRZDatabase version="1.34" xmlns="http://xmldata.qrz.com">
<Session>
<Error>Not found: 4X1UF/QRP</Error>
<Count>50720</Count>
<SubExp>Thu Nov 11 00:00:00 2021</SubExp>
<GMTime>Mon Feb 15 05:39:58 2021</GMTime>
<Remark>cpu: 0.019s</Remark>
</Session>
</QRZDatabase>


Not much JTAlert can do if previous QSOs in your log or the XML lookup returns no data.

de Laurie VK3AMA


locked Re: Jtalert not fully updated

4X1UF Izzy Lavee
 

Different achievements, different awards and above all a challenge

בתאריך יום ב׳, 15 בפבר׳ 2021, 00:03, מאת Dave Garber ‏<ve3wej@...>:

I have seen several operator sign /qrp.   But if i work you. You are in my log without the qrp.   It matters not whether you are 20mw or 2k.   

Just wondering why it matters.    




On Sun., Feb. 14, 2021, 3:09 p.m. 4X1UF Izzy Lavee, <ham.4x1uf@...> wrote:
Hi
Got some complains that when I'm using 4X1UF/QRP  i do not appear as a valid callsign.
Can you please check ? This callsign is part of my main page at QRZ.com 4X1UF.

73

Izzy 4x1uf


locked Re: Jtalert not fully updated

asobel@...
 

Lauri

 

4X1UF is a friend of mine. I did warn him about the problem. I did also QSO him many times just to check out if I am heard. What you see below is a QSO of this morning. What’s the connection to B4?

Please explain why the Name and QTH are not displayed.

Usually I regard a callsign that does not display name or QTH as a pirate or a WSJT-X phony call and check him on QRZ. Are there other cases of none display?

 

Amos 4X4MF

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Monday, February 15, 2021 7:48 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Jtalert not fully updated

 

On 15/02/2021 3:58 pm, asobel@... wrote:

Laurie

 

This is the problem:

Amos 4X4MF


That looks correct. What's the problem? If it is the lack of a Name & QTH, that would be due to those fields not containing data in the previous QSO in your Log (where the B4 is coming from). If it was a new QSO and not a B4, the result would be the same as the QRZ XML returns the following...

<QRZDatabase version="1.34" xmlns="http://xmldata.qrz.com">
<Session>
<Error>Not found: 4X1UF/QRP</Error>
<Count>50720</Count>
<SubExp>Thu Nov 11 00:00:00 2021</SubExp>
<GMTime>Mon Feb 15 05:39:58 2021</GMTime>
<Remark>cpu: 0.019s</Remark>
</Session>
</QRZDatabase>


Not much JTAlert can do if previous QSOs in your log or the XML lookup returns no data.

de Laurie VK3AMA

3361 - 3380 of 36454