Date   

locked JTAlert 2.15.8 is available but multiple instances are still not showing.

asobel@...
 

Dear Laurie

 

I did upgrade to JTAlert 2.15.8, It does work Ok in 4 instances and  with my Log4OMV2 but Decode window  does still show only for the first instance. Same was for 2.15.7. Please repair this fault. I need decode window badly.

 

Amos 4X4MF

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: יום ו 24 ינואר 2020 22:56
To: Support@HamApps.groups.io
Subject: [Special] [HamApps] JTAlert 2.15.8 is available. Full Log4OMV2 support. #Announcement #NewRelease

 

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

This release has support for the newly released Log4OM V2. Both SQLite & MySQL logs are supported.
Log4OM V2 users should view the Help file for proper setup instructions (they are very simple).
See the "Settings -> Logging -> Log4OM V2" topic in the help file. Using the Help button when on the Log4OM V2 section of the JTAlert Settings window will take you to the relevant help topic.

de Laurie VK3AMA

The Release Notes...

2.15.8 (24-JAN-2020)

  *** Includes Callsign database file version 2020-01-24 (2020-January-24)

  New Features:

    - Log4OM V2: Full support for Log4OM V2, both SQLite and MySQL logs.

    - Log4OM V1/V2 SQLite logs: "Test" button to check log file selected is
       a valid SQLite file for the Log4OM version and contains QSO records.
       See Settings window, "Logging -> Log4OM..." sections.

    - Logging option: New "Do not check or report logging success/failure".
       This option when ticked (off by default) instructs JTAlert to not try
       and confirm that a QSO was logged by reading the Loggers log directly.
       Once the logging instruction has been sent, JTAlert goes back to normal
       operation, there are no delays or hangs as JTAlert is stuck waiting to
       confirm the QSO was logged. JTAlert will however still report a logging
       failure when it could not initially establish the TCP or UDP connection
       to the target logger.

  Changes:

    - MySQL support: libmysql.dll file updated to v6.1.10 (previously v5.1.37)

  Fixes:

    - ADIF logging: Excessive time to confirm QSO logged successfully when using
       large adif files. 200,000 record check now takes ~1 sec (previous ~45 secs)

 


locked Re: Can't get to JTALER "Manage Setting'

Ed Fuller
 

Laurie,  at Mike's suggestion I ran vc_redist.x86.exe and that solved the error opening settings.   I tried your test version and it also worked FB, but I'm not sure that is a fair test as I didn't roll back the 32 bit redist.  Anything else I can do to help?  I do have a restore point from before all the distros.

 

Ed

 

 


From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Sunday, January 26, 2020 12:56 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Can't get to JTALER "Manage Setting'

 

On 27/01/2020 4:33 am, Ed Fuller wrote:

I upgraded from Jtalert 2.15.7 to 2.15.8 and install went fine; however when I click on Manage Setting, it throw error msg to the effect 'VCRUNTIME140 is missing'.  Sure enough it is not in system32 as on another of my machines.  Shack computer is win7 home premium.   I'm logging to Dxkeeper.  Tried installing vc_redist.x64.exe (from Visual c + + redistribution for visual studio 2015 site) and vcruntime140.dll shows up in system32 folder and now has registry entries.  Did a restart, no joy.  I'm at dead end.  Since I'm using dxkeeper, wonder if an option to bypass the loading of this dll would be possible?  Any help appreciated, been using this for several years with no problem.  Really hate to lose access to future updates.

 

Ed WA5RHG

Ed,

I am unaware which file in JTAlert is causing this error. There are several 3rd party dll files used and they are likely compiled requiring the VC runtime, it is a very common requirement. JTAlert is a 32 bit application and all the dlls are 32 bit as well. Try installing the 32bit version of the VC runtime.

I am suspicious, given some recent reports, that the updated libmysql.dll file may be the cause. I have sent you a link to an new JTAlert build that has roll-backed the libmysql.dll version give that a try and let me know the results.

de Laurie VK3AMA


locked Re: Can't get to JTALER "Manage Setting'

HamApps Support (VK3AMA)
 

On 27/01/2020 4:33 am, Ed Fuller wrote:

I upgraded from Jtalert 2.15.7 to 2.15.8 and install went fine; however when I click on Manage Setting, it throw error msg to the effect 'VCRUNTIME140 is missing'.  Sure enough it is not in system32 as on another of my machines.  Shack computer is win7 home premium.   I'm logging to Dxkeeper.  Tried installing vc_redist.x64.exe (from Visual c + + redistribution for visual studio 2015 site) and vcruntime140.dll shows up in system32 folder and now has registry entries.  Did a restart, no joy.  I'm at dead end.  Since I'm using dxkeeper, wonder if an option to bypass the loading of this dll would be possible?  Any help appreciated, been using this for several years with no problem.  Really hate to lose access to future updates.

 

Ed WA5RHG

Ed,

I am unaware which file in JTAlert is causing this error. There are several 3rd party dll files used and they are likely compiled requiring the VC runtime, it is a very common requirement. JTAlert is a 32 bit application and all the dlls are 32 bit as well. Try installing the 32bit version of the VC runtime.

I am suspicious, given some recent reports, that the updated libmysql.dll file may be the cause. I have sent you a link to an new JTAlert build that has roll-backed the libmysql.dll version give that a try and let me know the results.

de Laurie VK3AMA


locked Re: Can't get to JTALER "Manage Setting'

Ed Fuller
 

Mike, that was it.  Thanks much, I would not have thought of that.  What a great program and a wonderful support group.

 

Ed WA5RHG

 


From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Michael Black via Groups.Io
Sent: Sunday, January 26, 2020 12:29 PM
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Can't get to JTALER "Manage Setting'

 

Try the 32 bit version.



On Jan 26, 2020, at 12:21 PM, Ed Fuller <emfuller70@...> wrote:



I upgraded from Jtalert 2.15.7 to 2.15.8 and install went fine; however when I click on Manage Setting, it throw error msg to the effect 'VCRUNTIME140 is missing'.  Sure enough it is not in system32 as on another of my machines.  Shack computer is win7 home premium.   I'm logging to Dxkeeper.  Tried installing vc_redist.x64.exe (from Visual c + + redistribution for visual studio 2015 site) and vcruntime140.dll shows up in system32 folder and now has registry entries.  Did a restart, no joy.  I'm at dead end.  Since I'm using dxkeeper, wonder if an option to bypass the loading of this dll would be possible?  Any help appreciated, been using this for several years with no problem.  Really hate to lose access to future updates.

 

Ed WA5RHG


locked Re: Can't get to JTALER "Manage Setting'

Michael Black
 

Try the 32 bit version.


On Jan 26, 2020, at 12:21 PM, Ed Fuller <emfuller70@...> wrote:



I upgraded from Jtalert 2.15.7 to 2.15.8 and install went fine; however when I click on Manage Setting, it throw error msg to the effect 'VCRUNTIME140 is missing'.  Sure enough it is not in system32 as on another of my machines.  Shack computer is win7 home premium.   I'm logging to Dxkeeper.  Tried installing vc_redist.x64.exe (from Visual c + + redistribution for visual studio 2015 site) and vcruntime140.dll shows up in system32 folder and now has registry entries.  Did a restart, no joy.  I'm at dead end.  Since I'm using dxkeeper, wonder if an option to bypass the loading of this dll would be possible?  Any help appreciated, been using this for several years with no problem.  Really hate to lose access to future updates.

 

Ed WA5RHG


locked Can't get to JTALER "Manage Setting'

Ed Fuller
 

I upgraded from Jtalert 2.15.7 to 2.15.8 and install went fine; however when I click on Manage Setting, it throw error msg to the effect 'VCRUNTIME140 is missing'.  Sure enough it is not in system32 as on another of my machines.  Shack computer is win7 home premium.   I'm logging to Dxkeeper.  Tried installing vc_redist.x64.exe (from Visual c + + redistribution for visual studio 2015 site) and vcruntime140.dll shows up in system32 folder and now has registry entries.  Did a restart, no joy.  I'm at dead end.  Since I'm using dxkeeper, wonder if an option to bypass the loading of this dll would be possible?  Any help appreciated, been using this for several years with no problem.  Really hate to lose access to future updates.

 

Ed WA5RHG


locked Re: JTAlert won't open

Jim Cooper
 

On 26 Jan 2020 at 6:56, edward bishop via Groups.Io
wrote:

Ok the crazy thing is that 2.15.8
works okay on one computer but not the
other, I had 2.15.7 it works but dx
keeper was logging a state In the
province for dx thanks
I have noticed for quite some time,
thru several versions, that in the lookup
info line if a previous lookup was USA
with a state shown, and the next lookup
is DX without a province the state info
is not cleared.

I didn't 'complain' as Laurie has had
enough on the plate lately to worry about
such a minor glitch, but it's probably why
you are getting a state in the province slot.

w2jc


locked Re: Worked B4 mainly on 5T5PA

rogich@...
 

I reloaded it a few times but thanks for explaination. .. Jerry


locked Re: JTAlert QRZ Lookup stopping

Morris WA4MIT
 

Hi Laurie thanks for your reply. Majority of times sleep is used is like at night when I am going to bed or leaving house for a period of time. I try to set sleep to never when going to be at radio and I generally do not leave Alert or other ham programs running only ham program I may leave on is HRD and only if not leaving the house but at night everything is closed then when stopping ham operation set sleep back on.
Thanks I will try to be more observant of any particular things happening. FT8 operation is so quick it is hard to follow exactly what happens if your in QSO. 
73 Morris WA4MIT 


locked Re: JTAlert V2.15.18 - Log4OM V2 Thank You

edward bishop
 

I have the same problem here on a win 10 lenovo thinkcentre pc. Now I have a hp win 10 pc 2.15.8 works good. I was told that some code was add so I’m using 2.15.6 works

Sent from Mail for Windows 10

 

From: Jan Chojnacki
Sent: Saturday, January 25, 2020 12:22 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert V2.15.18 - Log4OM V2 Thank You

 

[Edited Message Follows]

Welcome

So how do you explain it?

 

 

Old version of JT Alert uninstalled, registry cleaned, computer restart, installation of JT-Alert 2.5.18, program running -> OK, I go to Settings- Manage stettings and what?

 

Fatal ERROR - MySQL start failure -

And what should I do about it?

 

 

2.5.17 Beta 0001 works without a problem. newer versions unfortunately not.

 


locked Re: JTAlert 2.15.8 will not stay running

K8HW
 
Edited

Thanks Laurie. Using the alt layout shortcut fixed the problem for now.

I don't understand why Webroot is doing this when I shut it off! By the way, a user can go to https://my.webrootanywhere.com/ and login to Webroot and it will show you what files it has attacked. I think the biggest malware is Windows 10.

73 - K8HW - Dave


locked Re: JTAlert won't open

edward bishop
 

Ok the crazy thing is that 2.15.8 works okay on one computer but not the other, I had 2.15.7 it works but dx keeper was logging a state In the province for dx thanks

Sent from Mail for Windows 10

 

From: HamApps Support (VK3AMA)
Sent: Saturday, January 25, 2020 9:47 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert won't open

 

On 26/01/2020 3:35 am, edward bishop via Groups.Io wrote:

jt-alert 2.15.8 i get error when start WSJT-X or WSJT-Z when start JTDX it open . now when i hit setting on jt-alert  i get mysql start Failure program now exit . i rollback to jt-alert 2.15.6 everything works.


The problem is that something is preventing the MySQL client dll from loading (during the Settings startup). The difference between 2.15.6 and 2.15.8 is that the later has had additional code added to report on this failure, in previous versions it was failing quietly which caused problems for anyone using a Logger with MySQL logs, HRD & Log4OM.

At this time, I don't know the cause.

I suggest you stay with the older version, I strongly suggest at 2.15.7 rather than 2.15.6

de Laurie VK3AMA

 


locked Re: JTAlert 2.15.8 will not stay running

Stewart Wilkinson
 

I'm having similar problems with 2.15.8 and my BitDefender AV.

It complained when I first installed it yesterday, the AV actually stopped the installer copying/extracting JTAlert.exe to the desination folder, but adding an exception got past that and then it ran for a while yesterday, but today the AV has decided again that it doesn't like JTAlert adn a couple of the related files and keeps wanting to block them until I add more exceptiions.

I have submitted samples to BitDefender and I suspect it will take them a couple of days to fix things again.

(as it happens Today's updates for the DXLabs apps are also causing problems and I ahve submitted those for checking too).

--
Stewart G0LGS


locked Re: Logging to DXKeeper Trouble #DXLAB

Dale Drake
 

Well, I did some troubleshooting and found that the problem is that JTAlert has stopped sending the DXCC number, CQ zone and ITU zone in the ADIF file it sends to DXKeeper.  It sends them as zeros when it's for a call not worked before. Can some one please tell me how JTALert knows these when the call sign is?  I think I must have inadvertently changed something that is causing this.  Up until recently JTA 2.11.5 and DXK 15.3.1 has been working fine together so I don't think it's a problem with software.   How does JTAlert look up a call sign's DXCC prefix number, CQ zone and ITU zone?  
--
Dale, AA1QD


locked Re: JTAlert QRZ Lookup stopping

HamApps Support (VK3AMA)
 

On 26/01/2020 2:31 am, Morris WA4MIT via Groups.Io wrote:
After several days without this problem happening it started again today my computer has been on for couple of days and I started using sleep function again when away from computer for longer periods of time. Question for Mike and Anthony: Do you have sleep enabled on your ham radio computer?. I feel like this has something to do with this problem as I had disabled sleep for a few days and this did not occur. Another thing I noticed happening before the no lookup today was that Alert did a reset of the callsign before lookup. Alert erased the call sign then it appeared again with lookup info.
73 Morris WA4MIT
Morris,

In my experience, not all applications handle Windows going to sleep and later resuming. My suggestion, if you going to have Windows hibernate, than shutdown WSJT-X and JTAlert and start them again after Windows resumes. The startup times for WSJT-X and JTAlert are not that significant and the time taken troubleshooting broken behavior after a resume is far greater than the time take starting WSJT-X/JTAlert.

The QRZ lookup failing could be due to the hidden JTAlertV2.Manager application, which handles everything Internet related, dot being able to establish an Internet connection after you PC has come out of hibernation.

de Laurie, VK3AMA


locked Re: Worked B4 mainly on 5T5PA

HamApps Support (VK3AMA)
 

On 26/01/2020 2:21 pm, WB8ASI Herb wrote:
Thanks Laurie.  Where does JTAlert find the B4 QSO's? 
From you Log. All B4 checks are done with a direct read of your enabled loggers log file/database.

de Laurie, Vk3AMA


locked Re: JTAlert error messages

HamApps Support (VK3AMA)
 

On 25/01/2020 4:21 am, Michael Ernst wrote:

Here are my settings and they work on HRD First of all in WSJT-X, also check the Secondary UDP Server, as seen here (note that this one uses port 2333 in my setup, I think that is the default):

 

 

Then in JTAlert, change the port to use the one above, as shown here:

 

 

This works on mine.

 

73,

Mike, AE8U

Mike,

Based on those two settings being enabled and things are working for you indicates that the Settings are having no affect!

Both the WSJT-X ADIF broadcast and the JTAlert Last QSO transmission are doing the same thing, broadcasting an ADIF record of your recently logged QSO. If you logging application was using these ADIF broadcasts then you would be getting double logging of the QSO, because both WSJT-X and JTAlert are sending to the same UDP port.

Your JTAlert Settings window shows you have HRD logging enabled, so logging requests are via the HRDLogbook API, not the ADIF broadcasts. HRD does have very primitive logging support direct from WSJT-X via the depreciated ADIF broadcast. In the early days when that was introduced, many HRD users switched on using that facility as well as the keeping the JTAlert logging resulting in double-logging. In the case where they were taking the JTAlert logging as well as the ADIF broadcasts from WSJT-X and JTAlert, which you settings show, would end up with triple logging. This is my long-winded way of saying the settings you show are not having any effect since your not reporting triple-logging of QSOs.

de


locked Re: JTAlert error messages

 

Mike,

 

I lost your email and I have a problem. Please email me at dave.alexander1947@...

 

73’s

Dave

KA3PMW

 

From: Support@HamApps.groups.io On Behalf Of Michael Black via Groups.Io
Sent: Friday, January 24, 2020 12:58 PM
To: support@hamapps.groups.io
Subject: Re: [HamApps] JTAlert error messages

 

Turns out Webroot was blocking JTAlert.exe.  However JTAlert_AL.exe was allowed to run so Bill is up and running now.

 

I've help other people with Webroot blocking stuff like this.  It's a bit too aggressive and in this case we found the option that affected this was "silent and automatic" with no way to make exceptions.  It was blocking JTAlert from getting process data.  Don't know why the alternate version works though...should be doing the same thing.

 

de Mike W9MDB

 

 

 

 

On Friday, January 24, 2020, 10:29:59 AM CST, Bill-KC8WSM 070-1191 <kc8wsm@...> wrote:

 

 

Good morning.  I was able to get my HRD fixed and now JTAlert opens but I am getting error messages.  These are the two I have received.  I checked the boxes as instructed in the first message then I start receiving the second one.  I'm sure It's a simple fix but I can figure it out.  Any ideas?

 

image.png

 

image.png

 

ReplyForward

 


locked Re: Logging to DXKeeper Trouble #DXLAB

HamApps Support (VK3AMA)
 

On 26/01/2020 3:17 am, Dale Drake wrote:
yes I am running 2.11.5 of JTAlert.  Logging to DXK was always FB until just recently

Since your running such an old version of JTAlert, that hasn't seen the benefits of bug fixes and performance improvements, and your reported problems have only just occurred it is likely that recent changes to DXKeeper are behind the errors as JTAlert by your own admission has not changed (so its logging behavior will not have changed). Your updating DXKeeper and not JTAlert and suddenly there are problems, DXKeeper looks to me like it is the problem as it is the only application you have changed.

I am not saying that DXKeeper has a defect, just that a problem has surfaced with a very old JTAlert / recent DXKeeper combination. A JTAlert version that will not be receiving any fixes or patches!

Very likely JTAlert 2.11.5 is the root cause, but with no other reports from users running more recent JTAlert builds, it is likely the defect is not present in recent builds.

de Laurie, VK3AMA


locked Re: JTAlert won't open

HamApps Support (VK3AMA)
 

On 26/01/2020 3:35 am, edward bishop via Groups.Io wrote:
jt-alert 2.15.8 i get error when start WSJT-X or WSJT-Z when start JTDX it open . now when i hit setting on jt-alert  i get mysql start Failure program now exit . i rollback to jt-alert 2.15.6 everything works.

The problem is that something is preventing the MySQL client dll from loading (during the Settings startup). The difference between 2.15.6 and 2.15.8 is that the later has had additional code added to report on this failure, in previous versions it was failing quietly which caused problems for anyone using a Logger with MySQL logs, HRD & Log4OM.

At this time, I don't know the cause.

I suggest you stay with the older version, I strongly suggest at 2.15.7 rather than 2.15.6

de Laurie VK3AMA