Topics

locked Not logging some QSOs to DXKeeper. #DXLAB


Carl - WC4H
 

When I run wsjt-x with jtalerts, it will log my QSOs normally to DXKeeper.  Then, at random I get
FAILURE :  QSO Not logged!  popup.

ERROR Message: DXKeeper File : Unable to confirm QSO logged

NOTE: The QSO is staill saved dto the WSJT-X Log File.

It logs the QSO before the error and the QSO after the error.  The error may or may noit come up again.

Anything I can do?

73.
Carl - WC4H


Rob Kivell
 

This has happened to me maybe a dozen times in approx. three thousand logs.  In my case, I do not like programs to automatically launch on startup. 99 percent of the times it was because I did not start up DXKEEPER before I tried to make the log entry from JTA. In the few other cases I imagine it was just an anomaly that a reboot fixed. In several instances JTA it was not logged but when I checked my DX Log it was there. But as I mentioned before, The issue has not been a problem For me.

73 Rob kk4eun


On Jun 23, 2020, at 7:22 PM, Carl - WC4H via groups.io <wc4h.dx@...> wrote:

When I run wsjt-x with jtalerts, it will log my QSOs normally to DXKeeper.  Then, at random I get
FAILURE :  QSO Not logged!  popup.

ERROR Message: DXKeeper File : Unable to confirm QSO logged

NOTE: The QSO is staill saved dto the WSJT-X Log File.

It logs the QSO before the error and the QSO after the error.  The error may or may noit come up again.

Anything I can do?

73.
Carl - WC4H
<jtalert-not-logging-error.JPG>


Dave AA6YQ
 

+ AA6YQ comments below

When I run wsjt-x with jtalerts, it will log my QSOs normally to DXKeeper. Then, at random I get
FAILURE : QSO Not logged! popup.

ERROR Message: DXKeeper File : Unable to confirm QSO logged

NOTE: The QSO is staill saved dto the WSJT-X Log File.

It logs the QSO before the error and the QSO after the error. The error may or may noit come up again.

+ Is the QSO referred to by the "Unable to confirm QSO logged" message logged in DXKeeper?

73,

Dave, AA6YQ


HamApps Support (VK3AMA)
 

On 24/06/2020 10:22 am, Carl - WC4H via groups.io wrote:
When I run wsjt-x with jtalerts, it will log my QSOs normally to DXKeeper.  Then, at random I get
FAILURE :  QSO Not logged!  popup.

ERROR Message: DXKeeper File : Unable to confirm QSO logged

NOTE: The QSO is staill saved dto the WSJT-X Log File.

It logs the QSO before the error and the QSO after the error.  The error may or may noit come up again.

Anything I can do?

73.
Carl - WC4H

Despite the "Cannot confirm" message from JTAlert, does the QSO actually make it into the log? If so increase the "Check QSO Log Record" time under the Logging section of the Settings window. If you are performing a number of DXKeeper operations post logging, like uploads to online services, you may have to change the time to 10 or more seconds.

de Laurie VK3AMA


Carl - WC4H
 

No it does not log it to DX Keeper.  That is why I posted the error.  It then will continue to log other QSOs but it will fail again.  There's no predicting when.

I ALWAYS start DXKeeper and WSJT-X before JTAlerts.

73.
Carl - WC4h


Carl - WC4H
 

Hi Rob.

This has become a daily event.  And they are NOT being logged.  I wish it was once every 3000 QSOs.  That's just a anomally.

73.
Carl - WC4H


Dave AA6YQ
 

+ AA6YQ comments below

This has become a daily event. And they are NOT being logged. I wish it was once every 3000 QSOs. That's just a anomally.

+ So that we can see exactly what's going on, please do the following:

1. on the General tab of DXKeeper's Configuration window, check the "Log debugging info" box

2. the next time JT-Alert informs you that it was unable to verify that a QSO was logged to DXKeeper

2a. on the General tab of DXKeeper's Configuration window, uncheck the "Log debugging info" box

2b. attach the errorlog.txt file from your DXKeeper folder to an email message that specifies the callsign of the station with whom the QSO was not logged, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Carl - WC4H
 

OK Dave.

Will do, but I have no clue when it will happen again.

73.
Carl - WC4H


Dave AA6YQ
 

+ AA6YQ comments below

OK Dave.

Will do, but I have no clue when it will happen again.

+ There's no harm in leaving "log debugging info" enabled for a few days.

73,

Dave, AA6YQ


HamApps Support (VK3AMA)
 

On 25/06/2020 10:54 am, Carl - WC4H via groups.io wrote:
No it does not log it to DX Keeper.  That is why I posted the error.  It then will continue to log other QSOs but it will fail again.  There's no predicting when.

I ALWAYS start DXKeeper and WSJT-X before JTAlerts.

73.
Carl - WC4h

Tnx Carl,

If the QSOs are randomly not being logged, rather than just an erroneous not-logged report from JTAlert, that gives us somewhere to look.

Is this random non-logging a recent problem or have you been experiencing it in previous JTAlert releases? If it is only recent, a Windows Restart may be all that is needed, especially with the recent activity in Windows updates, a sure recipe for application misbehavior (in my experience and not just with JTAlert).

If a Windows restart doesn't correct the problem please do the following...

  • Enable debug recording via the "Settings -> Enable Debug Recording" JTAlert menu.
  • Restart JTAlert, that is close JTAlert and then start JTAlert.
  • Operate as normal logging QSOs to DXKeeper.
  • Once you encounter a failed logging use the "Help -> Contact Support" menu, to send me your JTAlert files for analysis. Include a note of the Callsign and UTC time of the failed logging.
  • Turn off debug recording.

de Laurie VK3AMA


Carl - WC4H
 

HI Laurie.

It's relatively recent, but yesterday it seems to have happened more frequently.  PC restart is one of the first things I do.

I may have hit upon the solution.  Last night, while having the DXKeeper debug on, I had previously turned off the logging to eQSL checkbox in JTAlerts.  There may be an issue with my eQSL since I moved.  However, in that case, I would expect that it would log it to DXKeeper and DXKeeper to give me an error that it was not uploaded to eQSL.

I'll continue using it and try the JTAlerts debugging and let you know.  

If it's the eQSL issue, then it should not happen while I have that tuned off and I will let you know as well.,  If I go two or three days without the problem, then I will think it was the eQSL logging.  

Thanks.
73.
Carl - WC4H


g4wjs
 

On 25/06/2020 14:03, Carl - WC4H via groups.io wrote:
HI Laurie.

It's relatively recent, but yesterday it seems to have happened more frequently.  PC restart is one of the first things I do.

I may have hit upon the solution.  Last night, while having the DXKeeper debug on, I had previously turned off the logging to eQSL checkbox in JTAlerts.  There may be an issue with my eQSL since I moved.  However, in that case, I would expect that it would log it to DXKeeper and DXKeeper to give me an error that it was not uploaded to eQSL.

I'll continue using it and try the JTAlerts debugging and let you know.

If it's the eQSL issue, then it should not happen while I have that tuned off and I will let you know as well.,  If I go two or three days without the problem, then I will think it was the eQSL logging.

Thanks.
73.
Carl - WC4H
Carl,

are you certain that these QSOs are not being logged to DXKeeper? I ask because a failure to upload to eQSL should not stop the QSO being logged to DXKeeper when requested to do so by JTAlert. What can happen is that the logging is delayed by online lookups, which take variable amounts of time, and when JTAlert attempts to confirm that the QSO has been successfully logged it sometimes doesn't find the record. This is due to timing issues as JTAlert does not know when the QSO is actually logged, it simply uses a timer to wait a while, you set that timer in the JTAlert settings.



--
73
Bill
G4WJS.


Carl - WC4H
 

Hi Bill.

I am absolutely sure.  It just happened againg.  That means that it was not the eQSL upload.  I mentioned eQSL for  full disclosure but as I now know, it is not the problem.

I have the debug log for day for this instance and I will now turn on the debug log for JTAlerts.  Like I said before, this is randome so there's no predicting when it will happen again.

Laurie:

I was sending some text messages during the use this time.  If the QSO partner is online, I often send a "Tnx QSO.  73.  Carl" message.  Sometimes that leads to a few exchanges which are like an extended QSOs and can be very interesting.

I'll keep an eye on it to see if the messages interfere.

73.
Carl - WC4H


Dave AA6YQ
 

+ AA6YQ comment sbelow

It's relatively recent, but yesterday it seems to have happened more frequently. PC restart is one of the first things I do.

I may have hit upon the solution. Last night, while having the DXKeeper debug on, I had previously turned off the logging to eQSL checkbox in JTAlerts. There may be an issue with my eQSL since I moved.

+ If that was the case, the failure should occur each time you log a QSO -- not sporadically.

However, in that case, I would expect that it would log it to DXKeeper and DXKeeper to give me an error that it was not uploaded to eQSL.

I'll continue using it and try the JTAlerts debugging and let you know.

If it's the eQSL issue, then it should not happen while I have that tuned off and I will let you know as well., If I go two or three days without the problem, then I will think it was the eQSL logging.

+ A DXKeeper errorlog that captures the failing scenario would eliminate the need for speculation. You can simultaneously enable the JT-Alert errorlogging that Laurie VK3AMA requested.

73,

Dave, AA6YQ


DAVID BERNHEISEL
 

I have noticed that sometimes the QSO is not displayed in the window of the Log QSOs tab. I have been able to make it reappear by terminating and then restarting DXKeeper. My theory is that the pointer used for the display of the incore database records gets corrupted. When the file is closed and reopened the pointers are resynched. Only a guess at what may be happening, but try it next time you see the error.

Dave - N2DPF

On 6/25/2020 9:00 AM, Carl - WC4H via groups.io wrote:
Hi Bill.
I am absolutely sure.  It just happened againg.  That means that it was not the eQSL upload.  I mentioned eQSL for  full disclosure but as I now know, it is not the problem.
I have the debug log for day for this instance and I will now turn on the debug log for JTAlerts.  Like I said before, this is randome so there's no predicting when it will happen again.
Laurie:
I was sending some text messages during the use this time.  If the QSO partner is online, I often send a "Tnx QSO.  73.  Carl" message. Sometimes that leads to a few exchanges which are like an extended QSOs and can be very interesting.
I'll keep an eye on it to see if the messages interfere.
73.
Carl - WC4H


Dave AA6YQ
 

+ AA6YQ comments below

I have noticed that sometimes the QSO is not displayed in the window of the Log QSOs tab. I have been able to make it reappear by terminating and then restarting DXKeeper. My theory is that the pointer used for the display of the incore database records gets corrupted. When the file is closed and reopened the pointers are resynched. Only a guess at what may be happening, but try it next time you see the error.

+ There is no evidence supporting that guess. The next time it happens, Dave, remove any Log Page Display filtering by clicking the X button in the Filter panel at the bottom of DXKeeper's Main window's "Log QSOs" tab.

+ The errorlog that Carl WC4H sent me showed that for the missing QSO, DXKeeper never received a "Log QSO" directive from JT-Alert.

73,

Dave, AA6YQ


Carl - WC4H
 

HI Laurie.

I uploaded the error via the menu item in JTAlerts.

Thanks.
Carl - WC4H


HamApps Support (VK3AMA)
 

On 26/06/2020 12:00 am, Carl - WC4H via groups.io wrote:
I was sending some text messages during the use this time.  If the QSO partner is online, I often send a "Tnx QSO.  73.  Carl" message.  Sometimes that leads to a few exchanges which are like an extended QSOs and can be very interesting.

I'll keep an eye on it to see if the messages interfere.

73.
Carl - WC4H

Carl,

I have your support request, but being a bit time poor at the moment, I won't be able to give it the attention needed until tomorrow. Sorry.

As a Test, and I know it will be difficult, can you restrict your use of the Text Messaging until the QSO has been logged and confirmed. I am curious if that may be causing some sort of conflict given that both operations involve TCP/IP comms.

de Laurie VK3AMA


Carl - WC4H
 

No problem Laurie.

Whenever you can do it.  

Many thanks.
Carl - WC4H


HamApps Support (VK3AMA)
 

On 27/06/2020 11:35 pm, Carl - WC4H via groups.io wrote:
Whenever you can do it.  

Many thanks.
Carl - WC4H

Carl,
  • Your JTAlert debug data shows you turned debug recording off @ 13:36:50, with new data being capture starting back @ 14:11:26, ~ 35 minutes of debug data was not captured.


  • From Dave AA6YQ I got the following information
    The errorlog shows the receipt of log directives for QSOs with
    KE0CH at 2020-06-25 13:41:03
    WB9DLC at 2020-06-25 13:43:11
    WW0E at 2020-06-25 13:44:44

    The errorlog does not show DXKeeper receiving a directive to log a QSO with WZ9B.

  • The logging events in question occurred during the period JTAlert debug recording was off, as a result there is nothing for me to examine.

  • However, JTAlert maintains logging activity files for each of the supported loggers, independent of the main debug recording setting. Your DXKeeper activity file shows that the DXK TCP logging instruction being sent for all 4 QSOs, including the WZ9B qso which didn't get logged. The times exactly matching the times seen in the DXK errorlog.
  • The TCP logging instruction for WZ9B was executed by JTAlert and was recorded in the activity file, but it was never received by DXKeeper, Without  the JTAlert debug data, it is impossible to know why it was not received. There may have been a TCP connection issue which would get recorded if debug recording was on.

I will need to get further debug data for another failed logging event. Please repeat the previous exercise and submit a new Support request. I don't think we need to include the DXK errorlog capture for this new test. I'll take the ongoing analysis of your problem off-list when I get your next set of files.

de Laurie VK3AMA