Date   

locked Re: 23 second JTAlert startup time

KD7YZ Bob
 

On 9/23/2020 16:52, HamApps Support (VK3AMA) wrote:


Sorry, while the log caching mechanism you describe exists within
JTAlert and is core to its operation, it is not part of the JTAlert
Oy. Just when I was resigned to accept the strange delay.
Thanks Laurie for clarifying.

--
73
Bob KD7YZ
AMSAT LM #901


locked Re: JTAlert question

Tim
 

That was not very nice to say about our neighbors to the north.



Tim - N8NEU
FN00ah



-------- Original message --------
From: "Barry via groups.io" <boat.anchor@...>
Date: 9/23/20 10:29 (GMT-05:00)
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert question

On Tue, Sep 22, 2020 at 05:16 PM, Bob Willey wrote:
I noticed something showing up recently, mostly Canada stations
shows their Callsign as RED in WSJT-X and JTAlert & Decodes
 
Don't remember seeing that before, unless I clicked on something.
 



 
photo  
Bob Willey
K3RLW

(410) 251-8960 | K3RLW@...

http://qrz.com/db/K3RLW

5161 Ocean Gateway, Trappe Maryland 21673-2023 USA
 

Bob

Bob
This is due to the fact Canadians have a red flag and are somewhat socialist.
cheers
Barry

 


locked Re: Click on spots

HamApps Support (VK3AMA)
 

On 23/09/2020 3:44 am, Neil wrote:
It had been working and somehow Windoze decided to uncheck the boxes when it did a recent update. MS thinks they are smarter than the users and think it knows what is best for us.
I appreciate and use ur program
73 and stay well.....Neil   N4FN

Windows won't have unchecked those check-boxes. That will have been due to either your WSJTX config (.ini) file being renamed/deleted or starting WSJTX with a new (previously unused) --rig-name parameter. All three check-boxes unchecked is the default setting.

de Laurie VK3AMA


locked Re: JTAlert question

HamApps Support (VK3AMA)
 

On 24/09/2020 12:29 am, Barry via groups.io wrote:
I noticed something showing up recently, mostly Canada stations
shows their Callsign as RED in WSJT-X and JTAlert & Decodes
 
Don't remember seeing that before, unless I clicked on something.

FYI,

Red text on a white background is the default coloring for the Wanted VE Province Alert.

de Laurie VK3AMA


locked Re: settings - JT-Alert

HamApps Support (VK3AMA)
 

On 22/09/2020 11:14 pm, dbushinsky wrote:

My computer will not allow me to install a newer version of JTAlert - it says I do not have permission to run the program.

thank you - 73 - David W2PD

What is the exact error message? Please post an image of the offending window (not your entire desktop).

de Laurie VK3AMA


locked Re: Jtalert2.16.13 is not logging with jtdx and HRD (latest version) #HRD

HamApps Support (VK3AMA)
 

On 24/09/2020 1:11 am, Gerard de Veer wrote:
I using now version 2.16.10 because when I Install 2.16.13 the qso's I make are not logged in HRD.

PD0GIP
OM,

When QSOs are not logged to HRD does JTAlert show an error message?

Provided you use the "OK" button on the WSJTX/JTDX "Log QSO" window JTAlert will log the QSO to HRD.

de Laurie VK3AMA


locked Re: JTalert "First QSO" permanently

HamApps Support (VK3AMA)
 

On 24/09/2020 12:24 am, Michael Black via groups.io wrote:
Have you done a scan & rebuild of the JTAlert database?


FYI,

A Rebuild Database operation does not affect the QSO History data of a Callsign. It is used for updating the needed entities for the Alerts.

Status messages like "First QSO" don't involve the Alert Database, they come from a direct read of the users Log.

de Laurie VK3AMA
 


locked Re: JTalert "First QSO" permanently

HamApps Support (VK3AMA)
 

On 24/09/2020 12:20 am, Jean-Claude F1DSZ wrote:
I am using JTalert version 2.16.13, and I've noticed for some time that when I contact a station, JTDX tells me
B4 signal but JTalert always announces "First QSO" permanently....view attachment.
A parameter would be at fault.
Thank you for your answer J. Claude F1DSZ


What you describe will occur if your logbook is empty or missing.
Do you have JTAlert set to use the correct (current active) HRD logbook. You may have it set to an old logbook.

de Laurie VK3AMA


locked Re: 23 second JTAlert startup time

HamApps Support (VK3AMA)
 

On 23/09/2020 10:02 pm, Bill Barrett wrote:
The first instance is reading the database from your log. The second
and additional instances get the data from cache.
Bill,

Sorry, while the log caching mechanism you describe exists within JTAlert and is core to its operation, it is not part of the JTAlert startup. There are no log lookups performed at startup.

de Laurie VK3AMA


locked Re: 23 second JTAlert startup time

HamApps Support (VK3AMA)
 

On 23/09/2020 7:41 pm, KD7YZ Bob wrote:
Windows 10-Pro x64
JTAlert 2.16.13 WSJTx 2.2.2

I run three instances of both.
The first instance of JTAlert ALWAYS takes circa 23 seconds to start.
The remaining two roughly 4-6 seconds individually.

I start JtAlert manually, waiting for the first one to finish. Then the
next and then the last.

It doesn't matter if I stop ALL and any A/V or other malware scanners.
HAMAPPS folder is listed as don't scan; JtAlert is the same.

If I stop all three JTAlert ... then begin the three again, the first
one takes 23 or so seconds to get started.

It doesn't matter time time of day or night.

So, since it's quite obviously NOT JTAlert, then someone gimme a hint
what computer setting I have messed up. This has been going on for at
least a month or so ... I've lost track of when I noticed it.


tnx

-- 73 Bob KD7YZ

Bob,

This sounds like PC protection interference to me.
Does your protection software go online to perform an analysis of suspect files? If so that would account for such a lengthy startup delay.

How long does it take for the "Reading Settings Data" window to display? It should appear within 1 second or less.
   

de Laurie VK3AMA


locked Re: Keyboard latency with multiple JTAlert processes running.

HamApps Support (VK3AMA)
 

On 23/09/2020 6:54 am:

Hey folks,

Sorry I'm sure this is an edge case, but I am a Flexradio user and I typically operate WSJT-X with at least 4 bands running simultaneously. I will feed each slice of the Flex to a different WSJT-X process, and then I will run an equal number of JTAlert instances, each capturing the UDP stream of the individual WSJT-X process.

I have noticed that as I add more JTAlert instances, my Keyboard latency will decrease linearly. By the time I have reached 4 processes, the latency is to the point where typing is very difficult.

My system is not taxed at all with all these programs running, I have a 12-core 4.0Ghz processor, and 32GB ram with a very fast GPU, and NVME storage. CPU usage while decoding 4 bands is 10- 20% & memory consumption is about 50%.

I have tried debugging for most of the day, and can confirm that the latency only happens with multiple JTalert instances running. I do not feel any keyboard sluggishness when I add more WSJT-x or Flexradio slices.


Has anyone encountered this before?

I am running version 2.16.13 of jtalert, 2.2.2 of WSJT-x and 15.8.0 of Dxkeeper.

Attached are some screenshots of my setup + a view of my system utilization when this is all running.

Thanks.

W9PDS
OM,

Try temporarily turning off monitor on all your WSJTX instances so there is no new decodes processing in WSJTX and by extension no new decodes processing in JTAlert. Do you still get the keyboard latency?

de Laurie VK3AMA


locked Re: JTalert "First QSO" permanently

Dave Garber
 

double check that the station is using the same grid as you had worked him before.  I have had a few times where this happens, especially if they use multi qth's...


Dave Garber
VE3WEJ / VE3IE


On Wed, Sep 23, 2020 at 10:47 AM Jean-Claude F1DSZ <f1dsz@...> wrote:
Yes I made a reconstruction of the database.
but how to make an analysis ?
  Thank you J. Cl. F1DSZ


locked Re: JTAlert 2.16.13 Rebuild Alert Database issue

Jim N6VH
 


On 9/23/2020 11:14 AM, KL7NW wrote:

After I got signed up for the HamApps.groups.io, I was able to search for more information about this issue.  I found and read the release notes for version 2.16.13.  I didn’t fully comprehend the notes when I did the upgrade, but I assume to correct this issue, I need to check the box "Auto clear triggered Alert entity after logging" for each type of alert and this  issue will be fixed.  It will be nice to let the software handle these needed alerts for me.

 

Please confirm if I understand this correctly.

 

Another part of the release notes says:

“2.16.13 (29-Aug-2020)
  *** Includes Callsign database file version 2020-08-29 (2020-Aug-29)”

 

Does this mean we no longer need to download and install your Alert Database when a new one is available?  Is the database included as part of the install for all new versions of JTAlert going forward?  If this is now an unnecessary step, why did you post a “HamApps.Databases.2020.08.29.Setup.exe” dated the same as JTAlert version 2.16.13?

 

I really like your product, but these notes didn’t make it very clear what you are doing in the release notes to me and others.  I’m sure whoever wrote it understood exactly what was intended!

 

Thank you,

John Gieringer / KL7NW

 

John,

"Auto clear triggered alert" should only be used in situations where you don't need a confirmation. For example, confirmations aren't needed for the Marathon, so I have that box checked in the Marathon alert section. For the awards where you do need a confirmation, don't check that box.

I find the release notes very clear and understandable (and, no, I didn't write them). For example, the section in the notes about Auto Clear Alert Triggers spells out exactly what it does, and is very specific in that it it should only be used in cases where you don't require any confirmation.

As far as the Callsign Database, it is probably there for those who haven't installed the latest version of JTAlert, but need the new database. While I think it is a good idea to keep up to date with the latest version of most programs, not everyone does.

73,

Jim N6VH


locked Re: JTAlert 2.16.13 Rebuild Alert Database issue

Jim N6VH
 


On 9/23/2020 6:52 AM, KL7NW wrote:

I use the audible alerts for new states and new countries, and I love this feature.  It has helped me complete 8-band WAS, and I’m close to completing 160m and 6m WAS.  I was helping a friend who is a little challenged with software settings and upgrades.  I upgraded his JTAlert to version 2.16.13 and also installed the JTAlert database.  We did a Rebuild Alert Database (sorry you renamed this feature as it confused my friend because he could not find Scan and Rebuild).  He was trying to go to Wanted States and uncheck the states he has confirmed contacts, and I explained that if he uses Rebuild Alert Database that those checkboxes will automatically get updated for him.

 

This doesn’t work as it did in the previous version.  It leaves states that he has confirmed already with the check box checked, which is incorrect, and providing him more confusion.

 

I verified this is happening on my JTAlert as well, and with another ham who upgraded to version 2.16.13.  It appears this is some bug in the software.  I also found that to have the Rebuild Alert Database function update all the bands, I have to go to Wanted States and check the boxes under all the bands, then go to Rebuild Alert Database.  If I didn’t do this, bands that were not checked end up with no states checked as if I didn’t need any states to alert.

 

Please let me know if I am doing something wrong, or if this is an issue you are working to correct.

 

John / KL7NW

 

_._,_._,_

John,

If the confirmed states still have the box checked as needed, then something is wrong, but I don't think it is JTAlert. After a Rebuild session, my WAS boxes are all correctly checked or not, depending on confirmation status. One thing that might cause a problem how you might have the confirmations checked in the Rebuild section. In WAS, for example, I only have LOTW checked. Then only QSO's that I have a LOTW confirmation for will be unchecked in the WAS aler section. You might already have this set correctly. If so, there is some other issue.

As far as updating all the bands, yes, you should check the bands you are interested in, and then you shouldn't have to do that again, unless you want to add or drop a particular band. For example, I'm not interested in 60 and 2, so I leave them unchecked.

73,

Jim N6VH


locked Re: JTAlert 2.16.13 Rebuild Alert Database issue

KL7NW
 

Bill,

 

We (3 of us) are all using Ham Radio Deluxe v6.7.0.3301 Logbook, WSJT-X v2.2.2, and JTAlert v2.16.13.

 

John Gieringer / KL7NW

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of g4wjs
Sent: Wednesday, September 23, 2020 13:22
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert 2.16.13 Rebuild Alert Database issue

 

John,

 

the answers to your questions will surely depend on whether you, and your friend, use one of the supported logging applications but you tell us nothing about that.

 

73
Bill
G4WJS.

 

On 23/09/2020 19:14, KL7NW wrote:

After I got signed up for the HamApps.groups.io, I was able to search for more information about this issue.  I found and read the release notes for version 2.16.13.  I didn’t fully comprehend the notes when I did the upgrade, but I assume to correct this issue, I need to check the box "Auto clear triggered Alert entity after logging" for each type of alert and this  issue will be fixed.  It will be nice to let the software handle these needed alerts for me.

 

Please confirm if I understand this correctly.

 

Another part of the release notes says:

“2.16.13 (29-Aug-2020)
  *** Includes Callsign database file version 2020-08-29 (2020-Aug-29)”

 

Does this mean we no longer need to download and install your Alert Database when a new one is available?  Is the database included as part of the install for all new versions of JTAlert going forward?  If this is now an unnecessary step, why did you post a “HamApps.Databases.2020.08.29.Setup.exe” dated the same as JTAlert version 2.16.13?

 

I really like your product, but these notes didn’t make it very clear what you are doing in the release notes to me and others.  I’m sure whoever wrote it understood exactly what was intended!

 

Thank you,

John Gieringer / KL7NW

 

 

 

From: john.kl7nw@... <john.kl7nw@...>
Sent: Wednesday, September 23, 2020 8:52
To: Support@HamApps.groups.io
Subject: JTAlert 2.16.13 Rebuild Alert Database issue

 

I use the audible alerts for new states and new countries, and I love this feature.  It has helped me complete 8-band WAS, and I’m close to completing 160m and 6m WAS.  I was helping a friend who is a little challenged with software settings and upgrades.  I upgraded his JTAlert to version 2.16.13 and also installed the JTAlert database.  We did a Rebuild Alert Database (sorry you renamed this feature as it confused my friend because he could not find Scan and Rebuild).  He was trying to go to Wanted States and uncheck the states he has confirmed contacts, and I explained that if he uses Rebuild Alert Database that those checkboxes will automatically get updated for him.

 

This doesn’t work as it did in the previous version.  It leaves states that he has confirmed already with the check box checked, which is incorrect, and providing him more confusion.

 

I verified this is happening on my JTAlert as well, and with another ham who upgraded to version 2.16.13.  It appears this is some bug in the software.  I also found that to have the Rebuild Alert Database function update all the bands, I have to go to Wanted States and check the boxes under all the bands, then go to Rebuild Alert Database.  If I didn’t do this, bands that were not checked end up with no states checked as if I didn’t need any states to alert.

 

Please let me know if I am doing something wrong, or if this is an issue you are working to correct.

 

John / KL7NW

 


--
73
Bill
G4WJS.


locked Re: JTAlert 2.16.13 Rebuild Alert Database issue

g4wjs
 

John,

the answers to your questions will surely depend on whether you, and your friend, use one of the supported logging applications but you tell us nothing about that.

73
Bill
G4WJS.

On 23/09/2020 19:14, KL7NW wrote:

After I got signed up for the HamApps.groups.io, I was able to search for more information about this issue.  I found and read the release notes for version 2.16.13.  I didn’t fully comprehend the notes when I did the upgrade, but I assume to correct this issue, I need to check the box "Auto clear triggered Alert entity after logging" for each type of alert and this  issue will be fixed.  It will be nice to let the software handle these needed alerts for me.

 

Please confirm if I understand this correctly.

 

Another part of the release notes says:

“2.16.13 (29-Aug-2020)
  *** Includes Callsign database file version 2020-08-29 (2020-Aug-29)”

 

Does this mean we no longer need to download and install your Alert Database when a new one is available?  Is the database included as part of the install for all new versions of JTAlert going forward?  If this is now an unnecessary step, why did you post a “HamApps.Databases.2020.08.29.Setup.exe” dated the same as JTAlert version 2.16.13?

 

I really like your product, but these notes didn’t make it very clear what you are doing in the release notes to me and others.  I’m sure whoever wrote it understood exactly what was intended!

 

Thank you,

John Gieringer / KL7NW

 

 

 

From: john.kl7nw@... <john.kl7nw@...>
Sent: Wednesday, September 23, 2020 8:52
To: Support@HamApps.groups.io
Subject: JTAlert 2.16.13 Rebuild Alert Database issue

 

I use the audible alerts for new states and new countries, and I love this feature.  It has helped me complete 8-band WAS, and I’m close to completing 160m and 6m WAS.  I was helping a friend who is a little challenged with software settings and upgrades.  I upgraded his JTAlert to version 2.16.13 and also installed the JTAlert database.  We did a Rebuild Alert Database (sorry you renamed this feature as it confused my friend because he could not find Scan and Rebuild).  He was trying to go to Wanted States and uncheck the states he has confirmed contacts, and I explained that if he uses Rebuild Alert Database that those checkboxes will automatically get updated for him.

 

This doesn’t work as it did in the previous version.  It leaves states that he has confirmed already with the check box checked, which is incorrect, and providing him more confusion.

 

I verified this is happening on my JTAlert as well, and with another ham who upgraded to version 2.16.13.  It appears this is some bug in the software.  I also found that to have the Rebuild Alert Database function update all the bands, I have to go to Wanted States and check the boxes under all the bands, then go to Rebuild Alert Database.  If I didn’t do this, bands that were not checked end up with no states checked as if I didn’t need any states to alert.

 

Please let me know if I am doing something wrong, or if this is an issue you are working to correct.

 

John / KL7NW



--
73
Bill
G4WJS.


locked Re: JTAlert 2.16.13 Rebuild Alert Database issue

KL7NW
 

After I got signed up for the HamApps.groups.io, I was able to search for more information about this issue.  I found and read the release notes for version 2.16.13.  I didn’t fully comprehend the notes when I did the upgrade, but I assume to correct this issue, I need to check the box "Auto clear triggered Alert entity after logging" for each type of alert and this  issue will be fixed.  It will be nice to let the software handle these needed alerts for me.

 

Please confirm if I understand this correctly.

 

Another part of the release notes says:

“2.16.13 (29-Aug-2020)
  *** Includes Callsign database file version 2020-08-29 (2020-Aug-29)”

 

Does this mean we no longer need to download and install your Alert Database when a new one is available?  Is the database included as part of the install for all new versions of JTAlert going forward?  If this is now an unnecessary step, why did you post a “HamApps.Databases.2020.08.29.Setup.exe” dated the same as JTAlert version 2.16.13?

 

I really like your product, but these notes didn’t make it very clear what you are doing in the release notes to me and others.  I’m sure whoever wrote it understood exactly what was intended!

 

Thank you,

John Gieringer / KL7NW

 

 

 

From: john.kl7nw@... <john.kl7nw@...>
Sent: Wednesday, September 23, 2020 8:52
To: Support@HamApps.groups.io
Subject: JTAlert 2.16.13 Rebuild Alert Database issue

 

I use the audible alerts for new states and new countries, and I love this feature.  It has helped me complete 8-band WAS, and I’m close to completing 160m and 6m WAS.  I was helping a friend who is a little challenged with software settings and upgrades.  I upgraded his JTAlert to version 2.16.13 and also installed the JTAlert database.  We did a Rebuild Alert Database (sorry you renamed this feature as it confused my friend because he could not find Scan and Rebuild).  He was trying to go to Wanted States and uncheck the states he has confirmed contacts, and I explained that if he uses Rebuild Alert Database that those checkboxes will automatically get updated for him.

 

This doesn’t work as it did in the previous version.  It leaves states that he has confirmed already with the check box checked, which is incorrect, and providing him more confusion.

 

I verified this is happening on my JTAlert as well, and with another ham who upgraded to version 2.16.13.  It appears this is some bug in the software.  I also found that to have the Rebuild Alert Database function update all the bands, I have to go to Wanted States and check the boxes under all the bands, then go to Rebuild Alert Database.  If I didn’t do this, bands that were not checked end up with no states checked as if I didn’t need any states to alert.

 

Please let me know if I am doing something wrong, or if this is an issue you are working to correct.

 

John / KL7NW

 


locked JTAlert 2.16.13 Rebuild Alert Database issue

KL7NW
 

I use the audible alerts for new states and new countries, and I love this feature.  It has helped me complete 8-band WAS, and I’m close to completing 160m and 6m WAS.  I was helping a friend who is a little challenged with software settings and upgrades.  I upgraded his JTAlert to version 2.16.13 and also installed the JTAlert database.  We did a Rebuild Alert Database (sorry you renamed this feature as it confused my friend because he could not find Scan and Rebuild).  He was trying to go to Wanted States and uncheck the states he has confirmed contacts, and I explained that if he uses Rebuild Alert Database that those checkboxes will automatically get updated for him.

 

This doesn’t work as it did in the previous version.  It leaves states that he has confirmed already with the check box checked, which is incorrect, and providing him more confusion.

 

I verified this is happening on my JTAlert as well, and with another ham who upgraded to version 2.16.13.  It appears this is some bug in the software.  I also found that to have the Rebuild Alert Database function update all the bands, I have to go to Wanted States and check the boxes under all the bands, then go to Rebuild Alert Database.  If I didn’t do this, bands that were not checked end up with no states checked as if I didn’t need any states to alert.

 

Please let me know if I am doing something wrong, or if this is an issue you are working to correct.

 

John / KL7NW

 


locked Re: 23 second JTAlert startup time

KD7YZ Bob
 

On 9/23/2020 08:02, Bill Barrett wrote:
The first instance is reading the database from your log. The second
and additional instances get the data from cache.
Well, Well! I am ignorant vis-a-vis JTAlert machinations I guess, Bill.
Many thanks indeed!

So I guess if my DxKeeper mdb is 13000 kb then that's a lot of reading-in .


tnx again.

--
73
Bob KD7YZ
AMSAT LM #901


locked Re: Keyboard latency with multiple JTAlert processes running.

Patrick Skerrett
 

I should note that I am current on .NET 4.8 with the  2020-KB4576484 update. 

 

4841 - 4860 of 36363