1. Topics
  2. jtalert not logging to dxkeeper

jtalert not logging to dxkeeper

Kurt Cathcart
 

This was all working before a hard drive crash.  After a resore, it seems that all is working well except for the jtalert logging to dxkeeper.

No alerts seem to show up on jtalert and when I log a QSO in FT8, it seems nothing gets passed to dxkeeper.

I've been through the config guid multiple times. https://www.dxlabsuite.com/dxlabwiki/GettingStartedwithK1JTModesWithJTAlert

Suggestions?
neil_zampella
 

I would take a look at WSJT-X to make sure that the UDP settings are correct.   Make sure all the checkboxes are checked.

Neil, KN3ILZ

On 11/19/2021 8:10 PM, Kurt Cathcart wrote:
This was all working before a hard drive crash.  After a resore, it seems that all is working well except for the jtalert logging to dxkeeper.

No alerts seem to show up on jtalert and when I log a QSO in FT8, it seems nothing gets passed to dxkeeper.

I've been through the config guid multiple times. https://www.dxlabsuite.com/dxlabwiki/GettingStartedwithK1JTModesWithJTAlert

Suggestions?

Dave AA6YQ
 

+ AA6YQ comments below

This was all working before a hard drive crash. After a restore, it seems that all is working well except for the jtalert logging to dxkeeper.

No alerts seem to show up on jtalert and when I log a QSO in FT8, it seems nothing gets passed to dxkeeper.

+ When you're using JT-Alert, DXLab applications are relatively passive: they receive directives - like "lookup callsign" and "log QSO" from JT-Alert, and then execute them.

+ Focus first on getting JT-Alert to correctly interoperate with WSJT-X. When that's working, then configure JT-Alert to correctly interoperate - one at a time -- with DXKeeper, DXView, SpotCollector, and Pathfidner.

73,

Dave, AA6YQ
Kurt Cathcart
 

OK, Thank you.  I was thinking that the problem was between jtalert and DXK.


I'll see if I can remedy the wsjt to jtalert problem.


-Kurt, KR2C

On 11/19/2021 11:20 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

This was all working before a hard drive crash. After a restore, it seems that all is working well except for the jtalert logging to dxkeeper.

No alerts seem to show up on jtalert and when I log a QSO in FT8, it seems nothing gets passed to dxkeeper.

+ When you're using JT-Alert, DXLab applications are relatively passive: they receive directives - like "lookup callsign" and "log QSO" from JT-Alert, and then execute them.

+ Focus first on getting JT-Alert to correctly interoperate with WSJT-X. When that's working, then configure JT-Alert to correctly interoperate - one at a time -- with DXKeeper, DXView, SpotCollector, and Pathfidner.

73,

Dave, AA6YQ
Dave AA6YQ
 

+ AA6YQ comments below

OK, Thank you. I was thinking that the problem was between jtalert and DXK.

+ There could be a problem between JT-Alert and DXKeeper, but if JT-Alert isn't interoperating with WSJT-X, JT-Alert will have nothing for DXKeeper to log.

+ Start upstream, and proceed downstream step-by-step:

WSJT-X => JT-Alert => DXKeeper

73,

Dave, AA6YQ
Kurt Cathcart
 

Here is what it looks like:


286    7.817274    127.0.0.1    127.0.0.1    UDP    156    52979 → 2237 Len=124

287    7.817347    127.0.0.1    127.0.0.1    ICMP    184 Destination unreachable (Port unreachable)


Not sure why this is happening but I'll ping the WSJT-X guys.


-Kurt, KR2C

On 11/20/2021 4:43 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

OK, Thank you. I was thinking that the problem was between jtalert and DXK.

+ There could be a problem between JT-Alert and DXKeeper, but if JT-Alert isn't interoperating with WSJT-X, JT-Alert will have nothing for DXKeeper to log.

+ Start upstream, and proceed downstream step-by-step:

WSJT-X => JT-Alert => DXKeeper

73,

Dave, AA6YQ
Kurt Cathcart
 

OK -


I got the comms between WSJTX and JTALERT working.  Now on to the next piece.  For the most part all is running well.  However, occasionally I'm getting an error message:


Logging warning

Error Message: DXKeeper File: Unable to confirm QSO Logged

Note: The QSO is still saved to the WSJT-X Log File


This seems to happen after a number of successfully logged QSOs.

Sometimes I get another error message:


Unable to Log QSO due to a lengthy directive from another DXLab application


Any ideas?


Also, How do I move the WSJT-X logs that weren't logged to DXK after the fact?


-Kurt, KR2C

On 11/20/2021 4:43 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

OK, Thank you. I was thinking that the problem was between jtalert and DXK.

+ There could be a problem between JT-Alert and DXKeeper, but if JT-Alert isn't interoperating with WSJT-X, JT-Alert will have nothing for DXKeeper to log.

+ Start upstream, and proceed downstream step-by-step:

WSJT-X => JT-Alert => DXKeeper

73,

Dave, AA6YQ
Dave AA6YQ
 

+ AA6YQ comments below

I got the comms between WSJTX and JTALERT working.

+ What changes did you make to accomplish this?


Now on to the next piece. For the most part all is running well. However, occasionally I'm getting an error message:


Logging warning

Error Message: DXKeeper File: Unable to confirm QSO Logged

+ That error message comes from JT-Alert. Was the QSO actually logged in DXKeeper?


Note: The QSO is still saved to the WSJT-X Log File

This seems to happen after a number of successfully logged QSOs.

Sometimes I get another error message:


Unable to Log QSO due to a lengthy directive from another DXLab application

+ That message from DXKeeper only appears when you attempt to log a QSO from DXKeeper's Capture window, but DXKeeper was busy processing a directive from another application for more than 30 seconds -- which should never happen.

Any ideas?

+ Together, these symptoms add up to "something is interfering with DXKeeper"; the most likely culprit is an anti-malware application not configured to consider DXKeeper to be safe, but there are other possibilities. See

https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference

Also, How do I move the WSJT-X logs that weren't logged to DXK after the fact?

+ WSJT-X maintains a log file in ADIF format. Open this file with a text editor, and locate the ADIF record for each QSO that should have been logged in DXKeeper, but wasn't. Create a new file named Missing.ADI, and place each missing ADIF record in this file. Then close Missing.ADI, and direct DXKeeper to import it.

73,

Dave, AA6YQ


-Kurt, KR2C

On 11/20/2021 4:43 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

OK, Thank you. I was thinking that the problem was between jtalert and DXK.

+ There could be a problem between JT-Alert and DXKeeper, but if JT-Alert isn't interoperating with WSJT-X, JT-Alert will have nothing for DXKeeper to log.

+ Start upstream, and proceed downstream step-by-step:

WSJT-X => JT-Alert => DXKeeper

73,

Dave, AA6YQ






--
This email has been checked for viruses by AVG.
https://www.avg.com
Kurt Cathcart
 

On 11/23/2021 5:48 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

I got the comms between WSJTX and JTALERT working.

+ What changes did you make to accomplish this?
++ I had the wrong version of .net


Now on to the next piece. For the most part all is running well. However, occasionally I'm getting an error message:


Logging warning

Error Message: DXKeeper File: Unable to confirm QSO Logged

+ That error message comes from JT-Alert. Was the QSO actually logged in DXKeeper?
++ It was not logged into DXKeeper.  That is probably why I got the manual logging error below.  What I have noticed is that when it fails, it seems to fail when DXK is auto uploading to LoTW or eQSL. I set JTAlert to not instruct DXK to auto upload and then I do it manually in DXK after I'm don with my radio time.  I haven't had a problem yet.


Note: The QSO is still saved to the WSJT-X Log File

This seems to happen after a number of successfully logged QSOs.

Sometimes I get another error message:


Unable to Log QSO due to a lengthy directive from another DXLab application

+ That message from DXKeeper only appears when you attempt to log a QSO from DXKeeper's Capture window, but DXKeeper was busy processing a directive from another application for more than 30 seconds -- which should never happen.

Any ideas?

+ Together, these symptoms add up to "something is interfering with DXKeeper"; the most likely culprit is an anti-malware application not configured to consider DXKeeper to be safe, but there are other possibilities. See

https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference

Also, How do I move the WSJT-X logs that weren't logged to DXK after the fact?

+ WSJT-X maintains a log file in ADIF format. Open this file with a text editor, and locate the ADIF record for each QSO that should have been logged in DXKeeper, but wasn't. Create a new file named Missing.ADI, and place each missing ADIF record in this file. Then close Missing.ADI, and direct DXKeeper to import it.
++  I do run Malwarebytes.  Thank you for the insight.
73,

Dave, AA6YQ


-Kurt, KR2C


On 11/20/2021 4:43 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

OK, Thank you. I was thinking that the problem was between jtalert and DXK.

+ There could be a problem between JT-Alert and DXKeeper, but if JT-Alert isn't interoperating with WSJT-X, JT-Alert will have nothing for DXKeeper to log.

+ Start upstream, and proceed downstream step-by-step:

WSJT-X => JT-Alert => DXKeeper

73,

Dave, AA6YQ
Dave AA6YQ
 

@ more AA6YQ comments below

++ I do run Malwarebytes. Thank you for the insight.

@ Quite a few users have reported interference from letting Malware Bytes run in the background. I only use it to conduct occasional scans.

@ What happens when you disable it?

73,

Dave, AA6YQ
Kurt Cathcart
 

So it seems that the manual method also has flaws.  LoTW so far uploads fine.  eQSL looks like it uploads 3-4 contacts then gets stuck.  I need to force DXK to shut down. I disable Malwarebytes, CCleaner and Defender with no change in behaviour.


-Kurt, KR2C

On 11/24/2021 9:03 AM, Dave AA6YQ wrote:
@ more AA6YQ comments below

++ I do run Malwarebytes. Thank you for the insight.

@ Quite a few users have reported interference from letting Malware Bytes run in the background. I only use it to conduct occasional scans.

@ What happens when you disable it?

73,

Dave, AA6YQ
Dave AA6YQ
 

+ AA6YQ comments below
So it seems that the manual method also has flaws.  LoTW so far uploads fine.  eQSL looks like it uploads 3-4 contacts then gets stuck.  I need to force DXK to shut down. I disable Malwarebytes, CCleaner and Defender with no change in behaviour.

+ Please do the following:

1. reboot Windows into "Safe Mode with Networking"

2. start DXKeeper

3. direct DXKeeper to submit 6 QSOs to eQSL

+ What happens?

      73,

           Dave, AA6YQ
Kurt Cathcart
 

That seemed to work fine.  I'll look elsewhere for my problem.  Thanks for the help.


-Kurt

On 11/24/2021 11:05 AM, Dave AA6YQ wrote:
+ AA6YQ comments below
So it seems that the manual method also has flaws.  LoTW so far uploads fine.  eQSL looks like it uploads 3-4 contacts then gets stuck.  I need to force DXK to shut down. I disable Malwarebytes, CCleaner and Defender with no change in behaviour.

+ Please do the following:

1. reboot Windows into "Safe Mode with Networking"

2. start DXKeeper

3. direct DXKeeper to submit 6 QSOs to eQSL

+ What happens?

      73,

           Dave, AA6YQ
Dave AA6YQ
 

+ AA6YQ comments below
That seemed to work fine.  I'll look elsewhere for my problem.  Thanks for the help.

+ That means one or more of the applications that Windows is automatically starting when booted "normally" is interfering with DXKeeper. The culprit is usually anti-malware. You're already aware of the "Getting Started" article on this topic.

      73,

            Dave, AA6YQ

    
     
1 - 14 of 14