Date   

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. 

 


locked Re: Keyboard latency with multiple JTAlert processes running.

Michael Black
 

Next thing is to try DriverEasy and see if you don't have some drivers to update.

Mike W9MDB




On Wednesday, September 23, 2020, 10:56:39 AM CDT, Patrick Skerrett <patrick@...> wrote:


Yes we did & also ran through the DISM. Just for completeness we also changed keyboards (ensured we are not using anything wireless, etc). 

I'm open to try anything, but feel free to read through my post & view the video. These fixes proposed are for general USB latency or latency only under high system load. In this use-case its specifically deteriorates with more instances of jtalert running. 



locked Re: Keyboard latency with multiple JTAlert processes running.

Patrick Skerrett
 

Yes we did & also ran through the DISM. Just for completeness we also changed keyboards (ensured we are not using anything wireless, etc). 

I'm open to try anything, but feel free to read through my post & view the video. These fixes proposed are for general USB latency or latency only under high system load. In this use-case its specifically deteriorates with more instances of jtalert running. 



locked Re: Keyboard latency with multiple JTAlert processes running.

Michael Black
 

Have you tried uninstalling your keyboard driver?

Mike W9MDB




On Wednesday, September 23, 2020, 10:26:23 AM CDT, Patrick Skerrett <patrick@...> wrote:


Hi Mark, I have been through those steps yesterday and spent a significant amount of time ensuring that the correlation between keyboard latency & JTAlert is not just a 'canary'. I have also created a video show how the system behaves as jtalert is scaled up. Notice the only thing changing here is additional instances of jtalert being brought up, but my typing becomes next to impossible even with a 15% cpu load:

 

 

https://youtu.be/G97HrJ9k7sE


locked Re: Keyboard latency with multiple JTAlert processes running.

Patrick Skerrett
 

Hi Mark, I have been through those steps yesterday and spent a significant amount of time ensuring that the correlation between keyboard latency & JTAlert is not just a 'canary'. I have also created a video show how the system behaves as jtalert is scaled up. Notice the only thing changing here is additional instances of jtalert being brought up, but my typing becomes next to impossible even with a 15% cpu load:

 

 

https://youtu.be/G97HrJ9k7sE


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

Gerard de Veer <gerard@...>
 

I using jtalert for more than a year
I using now version 2.16.10 because when I Install 2.16.13 the qso's I make are not logged in HRD.
I checked everything but I don't find the errors
All UDP ports that I need are open.


PLEASE HELP????

PD0GIP 

3281 - 3300 of 34798