Date   

locked Re: 2.15.9 Trojan virus warning

Lou Laderman W0FK
 

Thanks for the link. Although it advises sending the info to my malware provider for advice, since the warning came from Microsoft software, I’ll pass on that because I’m too old to wait for an answer from the company that never gives a straight answer to anything.

73, Lou W0FK 


locked Re: 2.15.9 Trojan virus warning

m_scot_alex
 
Edited


locked 2.15.9 Trojan virus warning

Lou Laderman W0FK
 

I’ve downloaded 2.15.9 but my antivirus program (Windows Defender) has quarantined it with a Trojan virus warning. I downloaded it on a second PC running Norton and no warning was given. Suggestions how to address this other than waiting for the next release and seeing if the issue manifests itself again?

73

Lou, W0FK 


locked Re: JTAlert 2.15.9 - Question

HamApps Support (VK3AMA)
 

On 7/02/2020 3:34 pm, James F. Boehner, MD via Groups.Io wrote:

Hopefully I haven’t missed something, but I have a question.

I do not have my primary log file incorporated within JT Alert.  I do have the wsjtx_log.adi file that is in my WSJT-X program.  Is that the adif file that should be imported into v2.15.9 JTALERT to continue the B4 alerting?

TIA

’73 de JIM N2ZZ

Jim,

The choice is yours. You could use an ADIF export from your primary logger or use the wsjtx_log.adi provided it contains all your QSOs.

de Laurie VK3AMA


locked B4 bug or feature?

Marc VK3OHM
 

I have just worked C21PF. He does not do LOTW or eQSL. I have my flags set to not display calls unless they do either LOTW or eQSL. He did not display in JTAlert (correct), but nevertheless, I decided to work him.

When I see his decode (in WSJT-X) in subsequent cycles, he is not greyed out, i.e. there is no B4 indication in WSJT-X. Now, I can understand why this might be - because he's not displaying in JTAlert, he is not being color coded in WSJT-X. Whilst I can understand how this could happen, is it really correct behavior?

I have worked him B4, therefore I expect to see him color coded in WSJT-X. Whether he does LOTW or eQSL is an unrelated issue.


locked JTAlert 2.15.9 - Question

James F. Boehner, MD
 

Laurie,

 

Hopefully I haven’t missed something, but I have a question.

 

I do not have my primary log file incorporated within JT Alert.  I do have the wsjtx_log.adi file that is in my WSJT-X program.  Is that the adif file that should be imported into v2.15.9 JTALERT to continue the B4 alerting?

 

TIA

 

’73 de JIM N2ZZ

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Thursday, February 06, 2020 8:11 PM
To: Support@HamApps.groups.io
Subject: [Special] [HamApps] JTAlert 2.15.9 is available. New Features & Fixes. #Announcement #NewRelease

 

The Latest JTAlert version 2.15.9 is now available @ https://hamapps.com/JTAlert/

*** Important for "NO Log" users ***. Users who don't have a logger enabled in JTAlert rely on the JTAlert maintained B4 Log Database for Worked B4 alerting.
This database file has changed significantly and requires that "NO Log" users only, perform an ADIF import to pre-populate the database with QSO data from their primary logger. If an import is not done, than B4 alerting will consider all decodes as new and never worked. This adif import is only required once after which JTAlert automatically updates the database with each QSO logged. See the "Logging -> Log B4 Database" section of the Settings.

New features include:

  • Continent of origin filtering of callsigns.
  • B4 alerting can now consider the on-air grid used (handy for catching roving stations that frequently change gridsquare).

Please review the Release notes at the end of this message.

de Laurie VK3AMA

Release Notes.

2.15.9 (06-FEB-2020)

  *** Includes Callsign database file version 2020-02-06 (2020-February-06)

  New Features:

    - Continent filtering of Callsigns: New filtering (hiding) of Callsigns based on
       Continent of origin of the callsign. All Continents by default are enabled.
       When one or more Continents are unchecked, any decodes originating from that
       Continent will not be displayed on the main JTAlert window REGARDLESS of any
       Alert they may have generated or any of the other Filters set. This does not
       affect the Decodes window which already has its own method of hiding decodes
       based on Continent of origin, it is not compatible with the Main window filter.

    - Worked B4: New "Ignore Grid" option to consider on-air grid when performing
       B4 checks against the Log. A previously worked station that normally produces
       a B4 will now generate an alert if their on-air grid is different from previous
       QSOs in your Log and this option is OFF (unticked).
       (Default: ON, Window: Settings, Section: Alerts, Worked B4).

    - B4 Log Database: Now records the Date and Grid of QSOs logged. This will allow
       "NO Log" users to utilise the "Ignore Grid" and "Ignore Date" options for the
        Worked B4 alert. IMPORTANT, this only applies to "NO Log" users.

    - Sound Device: A sound keep-alive added to try and prevent sound devices going
       into power-save mode. This is useful for those Audio drivers that put the
       device to sleep if no audio has been played for some time causing the first
       part of the sound to be lost as the card comes out of sleep.
       (e.g. NVidia HDMI card drivers that don't provide a power-save setting but
        set the power-save on in the Registry, so not user adjustable).

  Changes:

    - MySQL support: libmysql.dll file (used by HRD and Log4OM MySQL logs) has
       been downgraded to the version used in all JTAlert releases except the
       recent 2.15.8 public release. A small number of users experienced MySQL
       errors when trying to open the JTAlert Settings.

    - B4 Log Database: The B4log.mdb file used for B4 checks when running with no
       logger enabled ("NO Log" in the titlebar) is now named B4logV2.mdb and is
       NOT compatible with the old B4log.mdb file. This will require "NO Log" users
       to perform an ADIF import to pre-populate the file with their B4 QSO data.
       See the "Logging -> Log B4 Database" section of the Settings.

    - JTAlertV2.Manager: Process is now forcibly terminated if found to be running
       when JTAlert is first started.

    - Text Messages: Long received messages that were not originally sent with
       embedded carriage returns are now automatically wrapped when being displayed.

    - Highlight WSJT-X DT: The option "Highlight Band Activity DT values that
       exceed threshold" has been removed. Highlighting DT values is still available
       in the JTAlert Decodes window.

  Fixes:

    - MySQL: "MySql Start Failure" message when trying to open the Settings window.

    - IOTA data: Not logged for Log4OM V1 & V2 MySQL logs.

    - Decodes Window: When running multiple JTAlert instances, decodes from one
       or more instances were not being displayed depending on startup sequence
       and if the Decodes window was closed and reopened during a JTAlert session.

    - Decodes Window: Missing decodes when running multiple JTAlert instances
       against several very busy bands resulting in UDP receive buffer overflow.

    - Alerting incorrect callsign: Decodes containing two callsigns only, flags
       the 2nd callsign as a gridsquare (when it is a non-standard callsign and
       the first 4 characters follow valid grid formatting) and incorrectly
       flags the 1st callsign as the transmitting callsign.
       eg. "P29ZL OL725PLZ" when OL725PLZ is Tx, JTAlert will alert on P29ZL.

    - Worked B4: Callsigns signing /MM, /R, /A, /P and /M failing worked B4 check.

    - Cocos Island: TI9A incorrectly shown as Cocos (Keeling) Islands. This is a
       cosmetic display defect only. All alerting and logging correctly used the
       dxcc #37 which is Cocos Island.

 


locked Re: 2.15.8 Fatal Error (MySql)

HamApps Support (VK3AMA)
 

On 7/02/2020 3:16 pm, Michael Black via Groups.Io wrote:
I identified the problem with Log4OMV2 -- it's the blasted awards matrix being checked on every QSO...takes 15 seconds for my system and somebody else is reporting over 30 seconds.  


de Mike W9MDB
Tnx Mike,

I cringed every time I had to run some tests against Log4OM2 and had to import an adif file to populate the logs, it is way too slow even on relatively small QSO count adif files.

If your happy that JTAlert is successfully logging the QSOs you can turn off the Log Check performed by JTAlert which avoids the JTAlert hang at the end of logging, because it is a single threaded executable, as it waits for the timeout before rechecking the log. Logging Section of the Settings, very last option checkbox (scroll down).
   

de Laurie VK3AMA


locked Re: 2.15.8 Fatal Error (MySql)

Michael Black
 

I identified the problem with Log4OMV2 -- it's the blasted awards matrix being checked on every QSO...takes 15 seconds for my system and somebody else is reporting over 30 seconds.  


de Mike W9MDB


On Thursday, February 6, 2020, 08:21:09 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 7/02/2020 12:30 pm, Bob Kozlarek WA2SQQ wrote:
I installed the MS patch and that fixed the Fatal Error. However, At the end of a contact I get a "Fail QSO Not Logged SQlite unable to confirm. I am using 2.15.8 JTALERT. Will 2.15.9 fix this?

Log4OM2 is significantly slower in writing the QSO to is log compared to Log4OM1. If the QSO is getting logged by JTAlert the warning indicates that the QSO hadn't yet been written to the log before JTAlert went off to check. You will need to increase the "Check QSO Log Record" time under the "Logging" section of the JTAlert Settings. You will need to do this regardless of the JTAlert version.

de Laurie VK3AMA
 


locked Re: 2.15.9

HamApps Support (VK3AMA)
 

On 7/02/2020 2:21 pm, rogich via Groups.Io wrote:
I do not get any worked B4 showing up. About half the callsigns I see are worked before. No change to my settings from .8.

If your B4s are no longer showing after the upgrade indicates that your run JTAlert with no logger enabled ("NO Log" in the titlebar). You need to do an one-off adif import as highlighted in the release announcements. Did you do that?

de Laurie VK3AMA


locked 2.15.9

rogich@...
 

I do not get any worked B4 showing up. About half the callsigns I see are worked before. No change to my settings from .8. Also only N7MDW comes through when NA excluded.  Thanks


locked Re: 2.15.8 Fatal Error (MySql)

HamApps Support (VK3AMA)
 

On 7/02/2020 12:30 pm, Bob Kozlarek WA2SQQ wrote:
I installed the MS patch and that fixed the Fatal Error. However, At the end of a contact I get a "Fail QSO Not Logged SQlite unable to confirm. I am using 2.15.8 JTALERT. Will 2.15.9 fix this?

Log4OM2 is significantly slower in writing the QSO to is log compared to Log4OM1. If the QSO is getting logged by JTAlert the warning indicates that the QSO hadn't yet been written to the log before JTAlert went off to check. You will need to increase the "Check QSO Log Record" time under the "Logging" section of the JTAlert Settings. You will need to do this regardless of the JTAlert version.

de Laurie VK3AMA
 


locked Re: 2.15.8 Fatal Error (MySql)

Bob Kozlarek WA2SQQ <wa2sqq@...>
 

I installed the MS patch and that fixed the Fatal Error. However, At the end of a contact I get a "Fail QSO Not Logged SQlite unable to confirm. I am using 2.15.8 JTALERT. Will 2.15.9 fix this?
--
The only dumb question are the ones we don’t ask.


locked JTAlert 2.15.9 is available. New Features & Fixes. #Announcement #NewRelease

HamApps Support (VK3AMA)
 

The Latest JTAlert version 2.15.9 is now available @ https://hamapps.com/JTAlert/

*** Important for "NO Log" users ***. Users who don't have a logger enabled in JTAlert rely on the JTAlert maintained B4 Log Database for Worked B4 alerting.
This database file has changed significantly and requires that "NO Log" users only, perform an ADIF import to pre-populate the database with QSO data from their primary logger. If an import is not done, than B4 alerting will consider all decodes as new and never worked. This adif import is only required once after which JTAlert automatically updates the database with each QSO logged. See the "Logging ->
Log B4 Database" section of the Settings.

New features include:
  • Continent of origin filtering of callsigns.
  • B4 alerting can now consider the on-air grid used (handy for catching roving stations that frequently change gridsquare).
Please review the Release notes at the end of this message.

de Laurie VK3AMA

Release Notes.

2.15.9 (06-FEB-2020)

  *** Includes Callsign database file version 2020-02-06 (2020-February-06)

  New Features:

    - Continent filtering of Callsigns: New filtering (hiding) of Callsigns based on
       Continent of origin of the callsign. All Continents by default are enabled.
       When one or more Continents are unchecked, any decodes originating from that
       Continent will not be displayed on the main JTAlert window REGARDLESS of any
       Alert they may have generated or any of the other Filters set. This does not
       affect the Decodes window which already has its own method of hiding decodes
       based on Continent of origin, it is not compatible with the Main window filter.

    - Worked B4: New "Ignore Grid" option to consider on-air grid when performing
       B4 checks against the Log. A previously worked station that normally produces
       a B4 will now generate an alert if their on-air grid is different from previous
       QSOs in your Log and this option is OFF (unticked).
       (Default: ON, Window: Settings, Section: Alerts, Worked B4).

    - B4 Log Database: Now records the Date and Grid of QSOs logged. This will allow
       "NO Log" users to utilise the "Ignore Grid" and "Ignore Date" options for the
        Worked B4 alert. IMPORTANT, this only applies to "NO Log" users.

    - Sound Device: A sound keep-alive added to try and prevent sound devices going
       into power-save mode. This is useful for those Audio drivers that put the
       device to sleep if no audio has been played for some time causing the first
       part of the sound to be lost as the card comes out of sleep.
       (e.g. NVidia HDMI card drivers that don't provide a power-save setting but
        set the power-save on in the Registry, so not user adjustable).

  Changes:

    - MySQL support: libmysql.dll file (used by HRD and Log4OM MySQL logs) has
       been downgraded to the version used in all JTAlert releases except the
       recent 2.15.8 public release. A small number of users experienced MySQL
       errors when trying to open the JTAlert Settings.

    - B4 Log Database: The B4log.mdb file used for B4 checks when running with no
       logger enabled ("NO Log" in the titlebar) is now named B4logV2.mdb and is
       NOT compatible with the old B4log.mdb file. This will require "NO Log" users
       to perform an ADIF import to pre-populate the file with their B4 QSO data.
       See the "Logging -> Log B4 Database" section of the Settings.

    - JTAlertV2.Manager: Process is now forcibly terminated if found to be running
       when JTAlert is first started.

    - Text Messages: Long received messages that were not originally sent with
       embedded carriage returns are now automatically wrapped when being displayed.

    - Highlight WSJT-X DT: The option "Highlight Band Activity DT values that
       exceed threshold" has been removed. Highlighting DT values is still available
       in the JTAlert Decodes window.

  Fixes:

    - MySQL: "MySql Start Failure" message when trying to open the Settings window.

    - IOTA data: Not logged for Log4OM V1 & V2 MySQL logs.

    - Decodes Window: When running multiple JTAlert instances, decodes from one
       or more instances were not being displayed depending on startup sequence
       and if the Decodes window was closed and reopened during a JTAlert session.

    - Decodes Window: Missing decodes when running multiple JTAlert instances
       against several very busy bands resulting in UDP receive buffer overflow.

    - Alerting incorrect callsign: Decodes containing two callsigns only, flags
       the 2nd callsign as a gridsquare (when it is a non-standard callsign and
       the first 4 characters follow valid grid formatting) and incorrectly
       flags the 1st callsign as the transmitting callsign.
       eg. "P29ZL OL725PLZ" when OL725PLZ is Tx, JTAlert will alert on P29ZL.

    - Worked B4: Callsigns signing /MM, /R, /A, /P and /M failing worked B4 check.

    - Cocos Island: TI9A incorrectly shown as Cocos (Keeling) Islands. This is a
       cosmetic display defect only. All alerting and logging correctly used the
       dxcc #37 which is Cocos Island.



locked Re: #fixed

David Rounds
 

Yes

On 2/6/2020 9:22 AM, Bob Kozlarek WA2SQQ wrote:
Is this for Windows 10?
--
The only dumb question are the ones we don’t ask.


locked Re: LOG4OM V2 - “Fatal Error, "MY SQL Start Failure"

Jim N6VH
 

Herb posted the link to the answer. However, I would like to add that Log4OM v2 does NOT need to be run in admin mode, except in certain situations. See page 11 of the Log4OM user guide. Even then, it might not be necessary to run JTAlert in admin mode, regardless of what they say in the guide. When I used Log4OM v1 in admin mode, I did not run JTAlert in admin mode, and everything work well.

73,

Jim N6VH

On 2/6/2020 6:09 AM, Bob Kozlarek WA2SQQ wrote:
I've applied to the JTALERT support group, but had no idea how long the approval takes. Decided to post here. My apology if this is not permitted.

I’ve been using LOG4OM V2 for about a week and decided last night to get WSJT / JTALERT running. I upgraded both programs to their latest versions. My Flex 6500 was on and both WSJT and JTALERT were open and running. Proper operation was verified with Log4OM V1.

Ø  Started the installation procedure described in the LOG4OM manual (below)

Ø  When I get to Step #5 below, I get Fatal Error, "MY SQL Start Failure"

Ø  Posted the problem on the LOG4OM forum and was told that it is a known JTALERT bug.  I found this strange since I’ve seen others say it’s working fine.

Ø  Last night I got to thinking and now wonder if the radio needs to be off, and perhaps also LOG4OM?

Ø  LOG4OM needs to be run in an ADMIN mode – how about JTALERT?

I appreciate any suggestions on how to get this running.

 

(The steps below refer to page 142 in the latest LOG4OM manual dated 5 FEB 2020)

 

1.Enable the Remote Control port in Log4OM V2 with a UDP Port number of 2241- OK

2.Create an "ADIF_MESSAGE" inbound connection in Log4OM V2 with a UDP Port number of 2235 - OK

3. Create a "JT_MESSAGE" inbound connection in Log4OM V2 called JTALERT REBROADCAST with a UDP Port number of 1240 - OK

4. In WSJT-X/WSJT-Z File/Settings/reporting check the boxes and set the ports as shown below. - OK

5.In JTAlert in settings/manage settings/Logging/Log4OM V2 in JTAlert, enable the "Send WSJT-X DX call to Log4OM" and "Enable Log4OM V2 Logging"

When I tried to do step #5 above, I got “Fatal Error, "MY SQL Start Failure"

I was unable to proceed beyond this point.

6.Set the Control port in JTAlert to match the port used in Log4OM V2 (Step 1.)

7.Set the ADIF_MESSAGE port in JTAlert to match the port used in Log4OM V2 (Step 2.)

8. In settings/manage settings/applications/WSJT-X/JTDX in JTAlert enable "Rebroadcast WSJT-X UDP Packets (received only)" and set the IP Address to 127.0.0.1 and UDP Port number to match that set in Log4OM V2 step 3


locked Re: #fixed

Bob Kozlarek WA2SQQ <wa2sqq@...>
 

Is this for Windows 10?
--
The only dumb question are the ones we don’t ask.


locked Re: LOG4OM V2 - “Fatal Error, "MY SQL Start Failure"

WB8ASI Herb
 

On February 6, 2020 at 9:09 AM Bob Kozlarek WA2SQQ <wa2sqq@...> wrote:

I've applied to the JTALERT support group, but had no idea how long the approval takes. Decided to post here. My apology if this is not permitted.

I’ve been using LOG4OM V2 for about a week and decided last night to get WSJT / JTALERT running. I upgraded both programs to their latest versions. My Flex 6500 was on and both WSJT and JTALERT were open and running. Proper operation was verified with Log4OM V1.

Ø  Started the installation procedure described in the LOG4OM manual (below)

Ø  When I get to Step #5 below, I get Fatal Error, "MY SQL Start Failure"

Ø  Posted the problem on the LOG4OM forum and was told that it is a known JTALERT bug.  I found this strange since I’ve seen others say it’s working fine.

Ø  Last night I got to thinking and now wonder if the radio needs to be off, and perhaps also LOG4OM?

Ø  LOG4OM needs to be run in an ADMIN mode – how about JTALERT?

I appreciate any suggestions on how to get this running.

 

(The steps below refer to page 142 in the latest LOG4OM manual dated 5 FEB 2020)

 

1.Enable the Remote Control port in Log4OM V2 with a UDP Port number of 2241- OK

2.Create an "ADIF_MESSAGE" inbound connection in Log4OM V2 with a UDP Port number of 2235 - OK

3. Create a "JT_MESSAGE" inbound connection in Log4OM V2 called JTALERT REBROADCAST with a UDP Port number of 1240 - OK

4. In WSJT-X/WSJT-Z File/Settings/reporting check the boxes and set the ports as shown below. - OK

5.In JTAlert in settings/manage settings/Logging/Log4OM V2 in JTAlert, enable the "Send WSJT-X DX call to Log4OM" and "Enable Log4OM V2 Logging"

When I tried to do step #5 above, I got “Fatal Error, "MY SQL Start Failure"

I was unable to proceed beyond this point.

6.Set the Control port in JTAlert to match the port used in Log4OM V2 (Step 1.)

7.Set the ADIF_MESSAGE port in JTAlert to match the port used in Log4OM V2 (Step 2.)

8. In settings/manage settings/applications/WSJT-X/JTDX in JTAlert enable "Rebroadcast WSJT-X UDP Packets (received only)" and set the IP Address to 127.0.0.1 and UDP Port number to match that set in Log4OM V2 step 3


 


locked LOG4OM V2 - “Fatal Error, "MY SQL Start Failure"

Bob Kozlarek WA2SQQ <wa2sqq@...>
 

I've applied to the JTALERT support group, but had no idea how long the approval takes. Decided to post here. My apology if this is not permitted.

I’ve been using LOG4OM V2 for about a week and decided last night to get WSJT / JTALERT running. I upgraded both programs to their latest versions. My Flex 6500 was on and both WSJT and JTALERT were open and running. Proper operation was verified with Log4OM V1.

Ø  Started the installation procedure described in the LOG4OM manual (below)

Ø  When I get to Step #5 below, I get Fatal Error, "MY SQL Start Failure"

Ø  Posted the problem on the LOG4OM forum and was told that it is a known JTALERT bug.  I found this strange since I’ve seen others say it’s working fine.

Ø  Last night I got to thinking and now wonder if the radio needs to be off, and perhaps also LOG4OM?

Ø  LOG4OM needs to be run in an ADMIN mode – how about JTALERT?

I appreciate any suggestions on how to get this running.

 

(The steps below refer to page 142 in the latest LOG4OM manual dated 5 FEB 2020)

 

1.Enable the Remote Control port in Log4OM V2 with a UDP Port number of 2241- OK

2.Create an "ADIF_MESSAGE" inbound connection in Log4OM V2 with a UDP Port number of 2235 - OK

3. Create a "JT_MESSAGE" inbound connection in Log4OM V2 called JTALERT REBROADCAST with a UDP Port number of 1240 - OK

4. In WSJT-X/WSJT-Z File/Settings/reporting check the boxes and set the ports as shown below. - OK

5.In JTAlert in settings/manage settings/Logging/Log4OM V2 in JTAlert, enable the "Send WSJT-X DX call to Log4OM" and "Enable Log4OM V2 Logging"

When I tried to do step #5 above, I got “Fatal Error, "MY SQL Start Failure"

I was unable to proceed beyond this point.

6.Set the Control port in JTAlert to match the port used in Log4OM V2 (Step 1.)

7.Set the ADIF_MESSAGE port in JTAlert to match the port used in Log4OM V2 (Step 2.)

8. In settings/manage settings/applications/WSJT-X/JTDX in JTAlert enable "Rebroadcast WSJT-X UDP Packets (received only)" and set the IP Address to 127.0.0.1 and UDP Port number to match that set in Log4OM V2 step 3


locked #fixed

F5GHP
 

Hello all,
"Manage setting" --> Wanted Prefix
Why I can't  input some prefix in the field ?

Thanks for all  and have good hunt 73 Jpierre


locked Re: JTAlert docked with WSJT-X and coming to foreground

Paul-N5DUP
 

Thank you, Sir!

Paul
N5DUP


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


On 6/02/2020 1:08 pm, Paul-N5DUP wrote:
I have apparently optioned JTAlert to pop tp the foreground on top of whatever is there. When I uncheck Enable Dock it unchecks but when I put it and WSJT-X down on the task bar, it and WSJT-X pop back up to the forground docked. Can someone tell me where and how I can change that?

Thanks,
Paul
N5DUP

"Applications -> WSJT-X / JTDX" section of the Settings window.

de Laurie VK3AMA