locked what causes this error?


Brad N8PC
 





I get this trying to run and don't know why?


HamApps Support (VK3AMA)
 

On 5/07/2021 3:15 pm, Brad N8PC wrote:




I get this trying to run and don't know why?

What version of JTAlert? If it is one of the 2.50.x builds, do you have the correct NET 5 "Desktop" runtime installed?
See this post... https://hamapps.groups.io/g/Support/message/35794


de Laurie VK3AMA


Brad N8PC
 
Edited



On 7/5/2021 5:27 PM, HamApps Support (VK3AMA) wrote:
On 5/07/2021 3:15 pm, Brad N8PC wrote:




I get this trying to run and don't know why?

What version of JTAlert? If it is one of the 2.50.x builds, do you have the correct NET 5 "Desktop" runtime installed?
See this post... https://hamapps.groups.io/g/Support/message/35794


de Laurie VK3AMA

I am running 2.50.0.2.0 version of JtAlert
WSJT-X  2.5.0-rc3 7eac85
Desktop version 5.0.7 .net

with a ryzen 5 2600 Boosted CPU to 3600 with 16 gigs of ram on a 1 TB SSD. on a computer less than 2 years old running the latest Windows 10,

sometimes it works other times it will exit out and then this error occurs. before you ask YES the UDP report is turned on and YES it is set in both programs to 224.0.0.1 port 2237.


Brad N8PC
 

UPDATE:

I am able to load it and see what goes but as soon as it receives a data packet from WSJT-X 2.50-rc3 7eac85 <64 bit install it quits and exits the JTAlert 2.5.0.2.<64 bit install

What should I be looking for? I am running Ham Radio Deluxe  6.7.0.357


HamApps Support (VK3AMA)
 

On 7/07/2021 2:03 am, Brad N8PC wrote:
I am able to load it and see what goes but as soon as it receives a data packet from WSJT-X 2.50-rc3 7eac85 <64 bit install it quits and exits the JTAlert 2.5.0.2.<64 bit install

What should I be looking for? I am running Ham Radio Deluxe  6.7.0.357

Since this is only occurring when a decode is received, it may be the log lookup that is performed for the decode that is causing problems.

Are you using a MSAccess log type in HRD? If so, that could be the problem.

A number of HRD 6 users have experienced unusual JTAlert behavior. The exact cause is unknown, but it is related to using an MSAccess log in HRD. The usual fix is to perform an export of your current log, create a new Log in HRD and import the previous export, then switch JTAlert to using that new Log. In a very small number of cases, creating a new HRD MSAccess log didn't correct the behavior, but upgrading to using a MariaDB log did. HRD themselves recommend using MariaDB rather than MSAccess type logs.

de Laurie VK3AMA


Brad N8PC
 

I'll check it out and get back to you on it

On 7/6/2021 4:05 PM, HamApps Support (VK3AMA) wrote:
On 7/07/2021 2:03 am, Brad N8PC wrote:
I am able to load it and see what goes but as soon as it receives a data packet from WSJT-X 2.50-rc3 7eac85 <64 bit install it quits and exits the JTAlert 2.5.0.2.<64 bit install

What should I be looking for? I am running Ham Radio Deluxe  6.7.0.357

Since this is only occurring when a decode is received, it may be the log lookup that is performed for the decode that is causing problems.

Are you using a MSAccess log type in HRD? If so, that could be the problem.

A number of HRD 6 users have experienced unusual JTAlert behavior. The exact cause is unknown, but it is related to using an MSAccess log in HRD. The usual fix is to perform an export of your current log, create a new Log in HRD and import the previous export, then switch JTAlert to using that new Log. In a very small number of cases, creating a new HRD MSAccess log didn't correct the behavior, but upgrading to using a MariaDB log did. HRD themselves recommend using MariaDB rather than MSAccess type logs.

de Laurie VK3AMA


Doug Gerard
 

When I created a new log for K2D prior to this year's 123 colonies event, I ran into this problem.  I had been having JTAlert do my logging into HRD logbook, version 6.7.0.301.  I had enabled a second call sign within JTAlert as some one suggested but it would still hang and fail with the same error.  I eventually changed the JTAlert setting to not enable HRD logging and let WSJT-X do it directly through its UDP broadcasting.  I logged over 500 FTx QSOs without a hitch, enjoying the new caller window in JTAlert which helped in the pileups.  I've now gone back to my using my usual database log in HRD and will continue to let WSJT-X do the logging via UDP.  Not really sure what, if any, the advantage of JTAlert offers by doing the logging with HRD.  I know "way back", WSJT could not do logging with HRD and that was the reason many of us used JTAlert. 


HamApps Support (VK3AMA)
 

On 9/07/2021 5:34 am, Doug Gerard wrote:
I've now gone back to my using my usual database log in HRD and will continue to let WSJT-X do the logging via UDP.  Not really sure what, if any, the advantage of JTAlert offers by doing the logging with HRD.

If your not using JTAlert for logging, that is, you don't have a logger enabled with JTAlert you severely restrict the usefulness of JTAlert. You loose...
  • Accurate Worked B4 detection.
  • Accurate Wanted entity detection and alerting.
  • The ability to automate the update the different Wanted Alerts (like dxcc, state, grid, etc) by scanning your log to determine what you need and don't need.
  • Previous QSO history lookup with you QSO partner.
  • No Online log uploads.
  • No XML lookups.

Without a logger enabled, you loose the benefit of 90% or more of the JTAlert functionality.

de Laurie VK3AMA