Date   

locked Re: JTAlert error alert

w4lde
 

Issue with the error I reported fixed.
A few days earlier I had used ADI Master program to review the JTAlert log. It showed one problem and I corrected it an saved it. I don’t think it caused the issue either since it’s help me in the past.
Yesterday the issue was caused by the crap/temp files left in the log sub folder. I ran my incremental backup program and replaced that folder.
I had not lost anything since I do a incremental backup of all my critical files when I shut down every evening.
I’m 99.9% sure the issue was not caused by JTAlert, thanks for a great program
Stay safe 73 de
Ron W4LDE


locked Re: Slow path to logging

Laurie, VK3AMA
 



On 18/02/2021 5:16 pm, Radio K0HB wrote:

Thanks for “hanging with me” on this Lauri.

Notice on the Log4OM “Configuration screen” I have an additional inbound at port 1240, not seen on your example.  I have unchecked that, and then nothing arrives at Log4OM.  So I’ve left it checked.


If unchecking the port 1240 setting stops logging that indicates that the logging is happening via that port and not via the configured JTAlert port 2335.

You have port 1240 listening to the JTAlert UDP resend (I guess that is it, 1240 is an unusual number, the default is 2334) of the WSJT-X UDP traffic. That is how Log4OM is picking up on the logging event. It also means that any additional log data you have entered in the JTAlert Log Fields area will not be getting logged. You can quickly check that by entering some unique string for the QSO partners name in the Log Fields of JTAlert and observing if that unique string gets logged. Based on your screen-captures and my interpretation of the problem it will not get logged.

There is never any need to have Log4OM listening to the JTAlert UDP resend traffic. Turn it off.

Your problem is that your JTAlert settings do not match the Log4OM settings.
  • You have the JTAlert inbound connection set to port 2235 in Log4OM.
  • You have the ADIF_Message port set to port 2335 in JTAlert.
The ports need to match. Set Log4OM to use port 2335 and turn off the port 1240 inbound connection.

How does that work now?

de Laurie VK3AMA


locked Re: Slow path to logging

Radio K0HB
 

Thanks for “hanging with me” on this Lauri.

 

Here are those screen shots.

 

 

 

Notice on the Log4OM “Configuration screen” I have an additional inbound at port 1240, not seen on your example.  I have unchecked that, and then nothing arrives at Log4OM.  So I’ve left it checked.

 

So here is where I’m at.

 

If I check the “Do not check or logging success/failure”, then I get acceptable transfer to Log4om, with about 6-9 seconds transit time.  This condition is acceptable to me.

 

If I uncheck that box, I get increased delay, and that delay can be influenced by increasing the “Check QSO Log Record” delay time.  At the lowest setting (5 seconds) the transit time is around 20 seconds.  At the 20 second setting the transit time is nearly a minute.

 

Since the “Do not check…..” option gives me acceptable performance, I’m willing to “drop the case” as some quirk at my end,  or continue to work with you if you would like.

 

73, Hans, K0HB

 

 

From: HamApps Support (VK3AMA)
Sent: Thursday, February 18, 2021 03:45
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

On 18/02/2021 12:31 pm, Radio K0HB wrote:

Forgot to include:

 

Using SQLite, and my log size is about 98,000 QSO’s.


98K records should not be a problem. I routinely run multi-million record sqlite files for testing purposes.

I wonder if there is something unusual within your Log4OM comms setup for receiving logging instructions from JTAlert. Is it setup correctly, per the JTAlert Help file,

"Settings -> Logging -> Log4OM V2" section.

Can you provide a screen-capture of your Log4OM settings? It should look something like this...


And the correct JTAlert setup like this...


de Laurie VK3AMA

 


locked Re: Help setting up B4

HamApps Support (VK3AMA)
 

On 18/02/2021 2:13 pm, Mark via groups.io wrote:

I have WSJT-X (Version 2.3.0) and JTAlert (Version 2.16.17) installed on my Windows 10 computer.

 

Both applications seem to run properly.

 

But I can’t get the B4 to appear for prior QSOs.  Precisely what steps (and settings) do I need to get the B4 indication enables?

 

Tnx & 73,

 

Mark, K6FG


All JTAlert B4 checks are done against the logger you have enabled in JTAlert. Note: B4 checks do not utilize the WSJT-X log file.

If you are not using a logger with JTAlert ("NO Log" shown in titlebar text), than JTAlert will use a special file just for B4 checks. However, this file starts off empty and only adds entries  when you log a QSO in WSJT-X. You can pre-populate this "B4 database" with old QSOs by doing an import from an adif file. See the "Logging -> Log B4 Database" section of the JTAlert Settings window if you want to do an import.

de Laurie VK3AMA



locked Re: Slow path to logging

HamApps Support (VK3AMA)
 

On 18/02/2021 12:31 pm, Radio K0HB wrote:

Forgot to include:

 

Using SQLite, and my log size is about 98,000 QSO’s.


98K records should not be a problem. I routinely run multi-million record sqlite files for testing purposes.

I wonder if there is something unusual within your Log4OM comms setup for receiving logging instructions from JTAlert. Is it setup correctly, per the JTAlert Help file,

"Settings -> Logging -> Log4OM V2" section.

Can you provide a screen-capture of your Log4OM settings? It should look something like this...


And the correct JTAlert setup like this...


de Laurie VK3AMA


locked Re: Slow path to logging

HamApps Support (VK3AMA)
 

On 18/02/2021 12:29 pm, Radio K0HB wrote:
File enroute.
Files received.

All looks perfectly normal. A total of 88 ms between when JTAlert receives the QSO logged UDP message from WSJT-X and when JTAlert has vinished sending the logging instruction to Log4OM. Note the 3 highlighted entries from the debug file.

@ 01:26:26:915 the RR73 decode from KS4OT received.
@ 01:26:31:650 the Logged QSO UDP message received from WSJT-X
@ 01:26:31:738 The Log4OM log TCP instruction had finished (662 bytes sent).

In the 88ms between when JTAlert received the logged QSO message from WSJT-X and when JTAlert has finished sending the TCP message to Log4OM JTAlert gathers the log field data (_Read_Log_Data instruction), combines that data with what came from WSJT-X (_Set_Log_Data instruction) clears & sets the B4 Cache for K4SOT and writes the single adif entry record to disk (_write_singleqso_log entry).



de Laurie VK3AMA


locked Help setting up B4

Mark
 

Hello all,

 

I have WSJT-X (Version 2.3.0) and JTAlert (Version 2.16.17) installed on my Windows 10 computer.

 

Both applications seem to run properly.

 

But I can’t get the B4 to appear for prior QSOs.  Precisely what steps (and settings) do I need to get the B4 indication enables?

 

Tnx & 73,

 

Mark, K6FG

 


locked Re: Slow path to logging

Micky Corrow
 

Nice call Mike on the exclusions.
That worked miracles on my older slow system.

Micky K1XH


locked Re: Slow path to logging

Radio K0HB
 

Forgot to include:

 

Using SQLite, and my log size is about 98,000 QSO’s.

 

 

Sent from Mail for Windows 10

 

From: HamApps Support (VK3AMA)
Sent: Thursday, February 18, 2021 00:14
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

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
 

File enroute.


locked Re: JTAlert error alert

HamApps Support (VK3AMA)
 

On 18/02/2021 11:23 am, w4lde wrote:
Yesterday I ran version 2.16.17 without any problems.  This evening I started JTAlert and its set to auto start WSJT-x and after thing seems loaded correctly
I got the following popup and an alert to a specific line number.  I uninstalled 2.16.17 and reinstalled 2.16.16 and the same error alert poped up.
I dont think its an alert issue but Im lost wee to start to trouble shoot.  Any help is appreciated.  The opoup is:




Thanks for help
73 de Ron W4LDE
Ron,

If JTAlert is not throwing this error immediately, Please use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

If your unable to send a support request let me know.

de Laurie VK3AMA


locked JTAlert error alert

w4lde
 

Yesterday I ran version 2.16.17 without any problems.  This evening I started JTAlert and its set to auto start WSJT-x and after thing seems loaded correctly
I got the following popup and an alert to a specific line number.  I uninstalled 2.16.17 and reinstalled 2.16.16 and the same error alert poped up.
I dont think its an alert issue but Im lost wee to start to trouble shoot.  Any help is appreciated.  The opoup is:




Thanks for help
73 de Ron W4LDE


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

 

 

 

3101 - 3120 of 36206