Date   

locked Re: Callsign Database V2020.02.06

Jim N6VH
 

I also use Norton 360. I tested this with the latest versions of Firefox, Edge and Chrome. I didn't get any error messages with any browser. Everything worked fine here. It might be something in your settings, either in your browsers, or in Norton.

73,

Jim N6VH

On 2/11/2020 8:38 AM, bmorris106@... wrote:
Try running the Database on both Firefox and Edge.  PC security software is Norton 360. 
on Edge I get this message

Can’t connect securely to this page

This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner.

On Firefox I get this;
Secure Connection Failed

An error occurred during a connection to dnl.hamapps.com. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

_._,_._,_



locked Re: Callsign Database V2020.02.06

bmorris106@...
 

Try running the Database on both Firefox and Edge.  PC security software is Norton 360. 
on Edge I get this message

Can’t connect securely to this page

This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner.

On Firefox I get this;
Secure Connection Failed

An error occurred during a connection to dnl.hamapps.com. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.


locked Re: JTAlert New error message

Paul-N5DUP
 

Laurie,

Thank you for your reply and answer.  I sincerely apologize for having to ask for help. I had read about the QSO confirmation time and in fact had already stretched it from 5 sec. to 10 sec. which did not help. I think maybe the ACLog .mdb log file got corrupted somehow because I overwrote the backup to it and no more problems confirming the QSO. Thank you and sorry for the trouble.

Paul
N5DUP


On Feb 10, 2020, at 8:19 PM, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 11/02/2020 11:42 am, Paul-N5DUP wrote:

So I have WSJT-X prompting me when it is ready to log a contact. Until now JTAlerts confirms that it is logging to ACLog and all was well. Now I am getting this message from JTAlert that says.

Failure: QSO not logged

Error Message: ACLOG File unable to confirm QSO logged 

Not sure what has changed but any ideas what I should look for?

I’m not sure what to look for. Any help appreciated.

Thank you,
Paul
N5DUP

This has been discussed many times.

This error message indicates that JTAlert was unable to confirm that the QSO was successfully logged. It does this by performing a direct read of your Loggers log file/database. JTAlert doesn't rely on the logging status produced by some loggers which have shown to incorrectly indicate successful logging even when failing to log the QSO. Also some loggers don't provide any feedback at all when logging via their API, so JTAlert always tries to confirm success/failure via a direct log/database read.

If the QSOs are indeed getting logged you will need to increase the "Check QSO Log Record" time. See the Logging section of the JTAlert Settings window.

Very likely the post logging activities being performed by your logger are being impacted by Internet access speeds resulting in later than normal logging. Typical examples are post logging XML lookups or posting the QSO to online logs.

de Laurie VK3AMA


locked Re: JTAlert New error message

HamApps Support (VK3AMA)
 

On 11/02/2020 11:42 am, Paul-N5DUP wrote:

So I have WSJT-X prompting me when it is ready to log a contact. Until now JTAlerts confirms that it is logging to ACLog and all was well. Now I am getting this message from JTAlert that says.

Failure: QSO not logged

Error Message: ACLOG File unable to confirm QSO logged 

Not sure what has changed but any ideas what I should look for?

I’m not sure what to look for. Any help appreciated.

Thank you,
Paul
N5DUP

This has been discussed many times.

This error message indicates that JTAlert was unable to confirm that the QSO was successfully logged. It does this by performing a direct read of your Loggers log file/database. JTAlert doesn't rely on the logging status produced by some loggers which have shown to incorrectly indicate successful logging even when failing to log the QSO. Also some loggers don't provide any feedback at all when logging via their API, so JTAlert always tries to confirm success/failure via a direct log/database read.

If the QSOs are indeed getting logged you will need to increase the "Check QSO Log Record" time. See the Logging section of the JTAlert Settings window.

Very likely the post logging activities being performed by your logger are being impacted by Internet access speeds resulting in later than normal logging. Typical examples are post logging XML lookups or posting the QSO to online logs.

de Laurie VK3AMA


locked Re: Callsign Database V2020.02.06

HamApps Support (VK3AMA)
 

On 11/02/2020 12:51 pm, bmorris106@... wrote:

 

Can’t connect securely to this page

This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner.

There is nothing wrong with or outdated about the HamApps SSL certificates.

The error your getting is likely coming from your Protection software or your browser. Try an different browser.

de Laurie VK3AMA


locked Re: Callsign Database V2020.02.06

bmorris106@...
 

No, that didn't work either

 

Can’t connect securely to this page

This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner.


locked JTAlert New error message

Paul-N5DUP
 

So I have WSJT-X prompting me when it is ready to log a contact. Until now JTAlerts confirms that it is logging to ACLog and all was well. Now I am getting this message from JTAlert that says.

Failure: QSO not logged

Error Message: ACLOG File unable to confirm QSO logged 

Not sure what has changed but any ideas what I should look for?

I’m not sure what to look for. Any help appreciated.

Thank you,
Paul
N5DUP


locked Re: Callsign Database V2020.02.06

Dave Morton
 


locked Callsign Database V2020.02.06

bmorris106@...
 

Can not download the database, getting this error;

Secure Connection Failed
An error occurred during a connection to dnl.hamapps.com. SSL received a record that exceeded the maximum permissible length.
Error code: SSL_ERROR_RX_RECORD_TOO_LONG
    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

Is there a fix, never had this problem before.

Thanks  Bob  WA3THL


locked Re: Decodes 2.15.9

John
 

Thanks Laurie for the explanation.

This box is very interesting and I was surprised when it just popped up with the new version.

I appreciate the use of your program. Thank you!

John W3ML


locked Re: Alaska

Bill - AA4M
 

On 02/09/2020 22:13:18, HamApps Support (VK3AMA) wrote:
On 10/02/2020 12:17 pm, Bill - AA4M wrote:
I reinstalled 2.15.8 which solved the problem.

BTW - I'm a retired computer programmer - I know what you're going through, hi!

73, Bill� AA4M
Bill,

Please check your log, did the offending Callsigns get logged with a grid or is it empty?

de Laurie VK3AMA


The grids are all there.

73, Bill  AA4M


locked Re: Alaska

HamApps Support (VK3AMA)
 

On 10/02/2020 12:17 pm, Bill - AA4M wrote:
I reinstalled 2.15.8 which solved the problem.

BTW - I'm a retired computer programmer - I know what you're going through, hi!

73, Bill  AA4M
Bill,

Please check your log, did the offending Callsigns get logged with a grid or is it empty?

de Laurie VK3AMA


locked Re: Alaska

Dave Garber
 

did you confirm on qrz that they are in fact alaska, and not one of the many I have seen , that are now on the mainland

Dave Garber
VE3WEJ / VE3IE


On Sun, Feb 9, 2020 at 4:34 PM Bill - AA4M <MrBill@...> wrote:
I just worked 2 different Alaskan stations on 17M FT8, but they continue to be displayed in my NOT "Worked-B4" color scheme.  All others on the band seem to be identified OK by JTAlert.  What does the program have against our 49th state?  :)

73, Bill  AA4M


locked Re: Alaska

Bill - AA4M
 

On 02/09/2020 18:04:40, HamApps Support (VK3AMA) wrote:
On 10/02/2020 11:17 am, Bill - AA4M wrote:
OK, I just worked a JA who was calling CQ.� My QSO was successfully logged into DXKeeper.� Then the same JA popped up again calling CQ and was NOT shown as B4.� I closed JTAlert and WSJT-X, restarted them, now the same JA is showing correctly as B4.

Bill,

What options to you have set for the Worked B4 Alert?

���

de Laurie VK3AMA


Just the same as yours:



I reinstalled 2.15.8 which solved the problem.

BTW - I'm a retired computer programmer - I know what you're going through, hi!

73, Bill  AA4M



locked Re: Alaska

HamApps Support (VK3AMA)
 

On 10/02/2020 11:17 am, Bill - AA4M wrote:
OK, I just worked a JA who was calling CQ.  My QSO was successfully logged into DXKeeper.  Then the same JA popped up again calling CQ and was NOT shown as B4.  I closed JTAlert and WSJT-X, restarted them, now the same JA is showing correctly as B4.

Bill,

What options to you have set for the Worked B4 Alert?

   

de Laurie VK3AMA


locked Re: Alaska

HamApps Support (VK3AMA)
 

On 10/02/2020 11:17 am, Bill - AA4M wrote:
Is there a link to 2.15.8 which I can reinstall until this problem is resolved?
Bottom of the page from where you download JTAlert, https://hamapps.com/JTAlert/

de Laurie VK3AMA


locked Re: Performance with big AC Log

HamApps Support (VK3AMA)
 

On 8/02/2020 8:38 am, Shel KF0UR wrote:
Are you referring to AC Log's List / Last xx setting?  if so, it's set to a few hundred, and doesn't seem to affect this issue (same time whether 50 or 500).

Tnx,

Shel KF0UR
Shei,

I was able to reproduce the significant delays in showing the filtering of the ACLog display based on the WSJT-X DX Call sent by JTAlert. For me it occurred when using a very large ACLog log file (57,000 QSOs) and I had ACLog set to display all entries. It didn't matter if the DXCall was for a recent call in the log, one of the first or if a Callsign known not to be in the log.

There is typically a few seconds (less than 3) delay after a DX Call change for JTAlert to gather data from the ACLog log and display in the Callsign QSO history and Confirmed/Worked display area. You can see this when JTAlert shows the Callsign (to the left of the log fields) and its Worked B4 or New Band or First QSO status below the Callsign. eg.


I was seeing ~ 40+ seconds delay before the Callsign showed in ACLog and it filtered its display despite JTAlert having much earlier displayed the Callsign data as retrieved directly from the ACLog log. ACLog is similarly very slow when clearing the DXCall, 40+ seconds to clear the Call and remove the display filter.

When I reran the tests with a 50 QSO limit on the ACLog display, again sending a Callsign known not to be in the Log, the Showing of the Callsign in ACLog took ~1 sec or less with a similar number for when the Callsign is cleared.

It looks to me like an ACLog display issue when showing a large number of entries (to be expected). It is not a JTAlert delay in sending the Call to ACLog and the return of lookup data to JTAlert from the direct queries directly against the ACLog log file is fast indicating it is unlikely a database indexing issue. or a full database scan.

de Laurie VK3AMA


locked Re: Audio Error?

Bill - AA4M
 

On 02/09/2020 15:13:49, HamApps Support (VK3AMA) wrote:
On 10/02/2020 8:55 am, Bill - AA4M wrote:
I think I don't understand how the "virtual cable" is actually supposed to work!

73, Bill� AA4M
You simply need to set JTAlert to use the virtual device or any device other than the one used by WSJT-X.
While JTAlert is assigned to use the same audio device as WSJT-X you will continue to get the audio devices match warning.

de Laurie VK3AMA


That worked, thanks Laurie!

73, Bill AA4M


locked Re: Alaska

Bill - AA4M
 

On 02/09/2020 14:52:56, Ron W3RJW via Groups.Io wrote:
Certain stations do not show as worked B4 in the latest version during a session. Laurie is working on it.  How about when you restart JTAlert ?
--
73
Ron, W3RJW
OK, I just worked a JA who was calling CQ.  My QSO was successfully logged into DXKeeper.  Then the same JA popped up again calling CQ and was NOT shown as B4.  I closed JTAlert and WSJT-X, restarted them, now the same JA is showing correctly as B4.

Is there a link to 2.15.8 which I can reinstall until this problem is resolved?

Thanks, Bill  AA4M


locked Re: Worked B4 with HRD

Gavin Bennett
 

Hi Laurie

 

Thanks, if I can be of any assistance with log files etc., please let me know, it is not a major issue as it self corrects on application restart.

 

I appreciate you providing this essential tool for WSJTx.

 

Regards

 

 

Gavin

ZL3GAV

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Monday, 10 February 2020 11:58
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Worked B4 with HRD

 

On 10/02/2020 9:41 am, Gavin Bennett wrote:

Since Saturday I have been able to observe the behaviour further, with NEW QSO's no showing as B4 status worked in JT Alert.

There is no difference if the "Ignore Grid" option is selected or not. If I restart the WSJYx/JTAlert, and HRD logbook sessions, those stations in JTAlert are showing correctly with their B4 status.

Thanks

Gavin
de ZL3GAV


Gavin,

I can't confirm the defect yet, but there have been enough reports to indicate a problem.

I am working on it but am hampered by having to create a new VM working environment in order to run a trial copy of HRD to complete the testing. Time is a bit short at the moment.

de Laurie VK3AMA