locked 2.5.0 -- AutoIt Error


HamApps Support (VK3AMA)
 

On 14/04/2021 1:49 am, David - AK2L wrote:
Clearly, JTAlert doesn't like being connected to my HRD installation.  This is not a new problem; it existing in earlier versions of JTAlert as well.  But with the earlier versions, it would usually happen only once when I changed a setting.  I would then restart JTAlert and all would be well until I changed another setting.  With v2.50, it happens every time.

I would be interested to hear from other HRD6 users to see if they have seen any problems.

For now, I will look at logging directly from WSJT-X or perhaps changing my logging program altogether.

There are several members of the JTAlert Test Team that use HRD logging. None have reported this issue.

What Log type are you using in HRD? Is it MSAccess? There have been numerous problems with HRD MSAccess logs in recent months that have affected JTAlert. They didn't crash JTAlert but typically caused significant slowdown. The fix in all cases was to create a new Log in HRDLogbook and then set the new log in JTAlert. The problem appears to be tied into the ODBC DSN that HRD uses for its logs. Creating a new DSN, which happens when creating a new log seems to clear the problem. Some MSAccess log users have converted to MariaDB which solved the problem for them.

de Laurie VK3AMA


David - AK2L
 

I believe it is MSAccess as I have never attempted to switch to another database.  If others are using HRD without trouble, then I will try your solution.

For now, I have changed the logging so that WSJT-X sends the QSO to HRD Logbook.  JTAlert is set to use an ADIF file.  Every few days, I will export an ADI from HRD and have JTAlert scan that for alert updates.

Note: I did try to have JTAlert send (UDP) the QSO to HRD, but HRD was not picking up the submode from a MFSK/FT4 QSO whereas it picked it up from WSJT-X just fine.  Bug perhaps?  Settings error on my part?

In any case, the logging issue is a small inconvenience and I love all the improvements in JTAlert.

Thanks for the great program.


WarrenG KC0GU
 

I am running JTAlert 2.50.0, WSJT-x v2.3.0, HRD Logbook V6.7.0.323 and having no issues with logging.  I do not use the MS Access DB, as Laurie has pointed out it is problematic, especially when HRD does updates.  I use the Maria SQL database, it appears to be more stable and faster with HRD.

Warren
KC0GU
You can contact me off group, I'm good in QRZ.


HamApps Support (VK3AMA)
 

On 14/04/2021 6:51 am, David - AK2L wrote:
Note: I did try to have JTAlert send (UDP) the QSO to HRD, but HRD was not picking up the submode from a MFSK/FT4 QSO whereas it picked it up from WSJT-X just fine.

Likely you haven't set the "Log FT4 as ADIF 3.1.0 ..." setting under the Logging Options (you will need to scroll the window down to find the setting).



de Laurie VK3AMA


David - AK2L
 

No, that wasn't it -- it was one of the first things I checked:


Here is my test scenario:
  1. Set HRD Logbook to receive QSOs via UDP
  2. Set both WSJT-X and JTAlert to send QSOs via UDP
  3. Set WSJT-X to FT4 and confirm that JTAlert detects the mode.
  4. In WSJT-X, create some QSOs manually and log them.
  5. HRD LB will show 2 entries for each QSO.  The one from JTAlert will be missing the FT4 submode, the one from WSJT-X will have it.


f8nhf
 

Hello
Laurie is right I am a user of HRD6 even with a powerful PC processor I had problems JTALert and HRD which broke my system 
I switched to Maria DB and I had no more problems on the net there is a tuto in French I put the link: https://on5vl.org/figeage-avec-hrd-non-merci/
73 Denis F8NHF


David - AK2L
 

Follow up to #34151
Here is an example of logging two calls with myself:

The first and third entries are from JTAlert.  The second and fourth are from WSJT-X.
The date, grid and submode are all missing.


David - AK2L
 

Denis,
Thank you.  You have convinced me to try Maria DB.
AK2L


Bob Frostholm
 

Laurie

Why does my Logging Options page look different than yours?

73

Bob

Ko6Lu
On 4/13/2021 4:45 PM, HamApps Support (VK3AMA) via groups.io wrote:

On 14/04/2021 6:51 am, David - AK2L wrote:
Note: I did try to have JTAlert send (UDP) the QSO to HRD, but HRD was not picking up the submode from a MFSK/FT4 QSO whereas it picked it up from WSJT-X just fine.

Likely you haven't set the "Log FT4 as ADIF 3.1.0 ..." setting under the Logging Options (you will need to scroll the window down to find the setting).



de Laurie VK3AMA


--
Bob
KO6LU


Laurie, VK3AMA
 



On 15/04/2021 4:07 am, Bob Frostholm wrote:
Why does my Logging Options page look different than yours?

Do you really want an answer?

The difference is that my screen-capture shows the checkbox display scrolled down to reveal the settings that were not in view. Note my image had a red rectangle around the scrollbar and part of my message read "(you will need to scroll the window down to find the setting)".

de Laurie VK3AMA


Bob Frostholm
 

Whoops... I apologize,,,,sorry to waste your time.

73

Bob

Ko6Lu
On 4/14/2021 11:18 AM, Laurie, VK3AMA via groups.io wrote:



On 15/04/2021 4:07 am, Bob Frostholm wrote:
Why does my Logging Options page look different than yours?

Do you really want an answer?

The difference is that my screen-capture shows the checkbox display scrolled down to reveal the settings that were not in view. Note my image had a red rectangle around the scrollbar and part of my message read "(you will need to scroll the window down to find the setting)".

de Laurie VK3AMA


--
Bob
KO6LU


HamApps Support (VK3AMA)
 

On 15/04/2021 1:45 am, David - AK2L wrote:
Follow up to #34151
Here is an example of logging two calls with myself:

The first and third entries are from JTAlert.  The second and fourth are from WSJT-X.
The date, grid and submode are all missing.

That looks like a previously reported HRD Logbook bug.

HRD in their infinite wisdom chose to implement an ADIF parser that requires the fields in a QSO record to be in a specific order and it breaks when it receives the ADIF data from JTAlert. The ADIF files, per the official ADIF specs, do not need the data to be in a specific order, it is not a CSV file where order is mandatory. HRD eventually acknowledged this defect rather than continually blaming JTAlert, and promised a fix. Either the fix has not been forthcoming or your running an old HRD version.

I tried matching the adif field order of the WSJT-X adif data, to work around this bug, but that failed because JTAlert includes additional data, like name, QTH, Solar data, State, Zones, etc that WSJT-X does not provide, and I was flying blind not knowing what the expected order was, it is not documented.

I suggest you make sure your HRD version is the latest and if the problem persists, contact HRD support end inquire about when the adif field order defect will be corrected.

de Laurie VK3AMA


David - AK2L
 

> I suggest you make sure your HRD version is the latest
It is the latest

> and if the problem persists, contact HRD support
I'll solve the real problem (I hope) by installing Maria DB and then I can use JTAlert's features again.


Laurie, VK3AMA
 

On 15/04/2021 4:29 am, Bob Frostholm wrote:
sorry to waste your time.
No need to be sorry. Not a waste of time.

Any responses I post to the group are then in the message archive for future generations.

de Laurie VK3AMA


David - AK2L
 

Denis and Laurie,

I installed MariaDB following the instructions from WA9PIE's 7-year-old YouTube video and it works great.

I then re-configured WSJT-X and JTAlert to let JTAlert do the logging for me.  Perfect!  No more AutoIT errors.  No more inexplicable shutdowns of JTAlert.

Thanks for the advice!


Laurie, VK3AMA
 

On 16/04/2021 10:00 am, David - AK2L wrote:
Denis and Laurie,

I installed MariaDB following the instructions from WA9PIE's 7-year-old YouTube video and it works great.

I then re-configured WSJT-X and JTAlert to let JTAlert do the logging for me.  Perfect!  No more AutoIT errors.  No more inexplicable shutdowns of JTAlert.

Thanks for the advice!
Good stuff!
Thanks for updating the group.

I think I will start recommending that HRD users who are experiencing unexplained slowdowns or errors that they upgrade their log to Maria and no longer suggest creating a new MSAccess log. Off the top of my head, I am not aware of any problems caused by the Maria upgrade, at least not when it comes to JTAlert inter-operation.

de Laurie VK3AMA


David Merchant - K1DLM
 

I'm getting an AutoIT error every time I try to launch JTAlert 2.50.  Specifically, the error says "Line 6817 (File C:\Program Files(x86)\HamApps\JTAlert\JTAlert.exe)  Error: Subscript used on non-accessible variable.

I was able to get it to load initially and was using the software.  However, it wouldn't let me select a station for my next QSO, so I tried restarting it.  That's when the error occured.

Any suggestions?

Thanks & 73,

Dave
K1DLM


HamApps Support (VK3AMA)
 

On 21/04/2021 11:25 am, David Merchant - K1DLM wrote:
I'm getting an AutoIT error every time I try to launch JTAlert 2.50.  Specifically, the error says "Line 6817 (File C:\Program Files(x86)\HamApps\JTAlert\JTAlert.exe)  Error: Subscript used on non-accessible variable.

I was able to get it to load initially and was using the software.  However, it wouldn't let me select a station for my next QSO, so I tried restarting it.  That's when the error occured.

Any suggestions?

Thanks & 73,

Dave
K1DLM

Try starting JTAlert without a config file. There may be something in the config that is tripping up JTAlert. See the JTAlert Help file (not the 2.50.0 features help), "Troubleshooting -> Setting Changes Not Remembered" topic. It explains where to find the config file. It may be worth trying to restore an old backup of the config.sqlite file first, explained in that help topic, before proceeding to starting JTAlert without a config file.

If starting JTAlert without a config file corrects the problem, I would greatly appreciate it if you could send me the problem config.sqlite file for examination. send it direct (not via this group) to VK3AMA.Ham.Apps [at] gmail.com

let me know your results.

de Laurie VK3AMA


Richard, PD3RFR
 

I've got the same error with line 6817 since upgrade to 2.50.1. Removed the config, still the same error. 
Uninstalled, reinstalled, went back to 2.16.17, the same error that appears then is the same, but in line 6875.
Unfortunately I have to run without JTAlert now. Hopefully someone comes with a quick solution.


Richard, PD3RFR
 
Edited

I don't know what I did, but I did a lot.. But it works again without errors.

Some steps, not in chronical order and maybe missing some steps:
Installed JTAlert 2.5.0.1., de-installed it, installed older version of JT (same error other line), reinstalled latest version. Deleted config, put config back, upgraded HRD in meanwhile, rebooted the PC several times.
Took a while. I'm happy now, sorry I can't reproduce.. or have the right solution. I think it had to do with the config.