Date   

locked Decodes Windows Dead; Corrupt SQL DB; How To Fix

TomK
 

[Nb. This is a spruced up and expanded version of a much earlier post of mine]

 

As with many, I’ve experienced the issue of the Decodes Window not auto-starting after opening.

The fix for some (and me) had been to close and restart the Decodes window, one or more times.

However, that doesn’t always work as it did not after my recent upgrade to v2.16.10.

I am sure it was *not* the upgrade but, rather, a crash of the Decodes sub-program (read on).

After 2-3 days of debugging, I forgot I had found a fix for the same permanent failure.

The problem had been for me, as it was now, due to be a corrupt Decodes SQLite database.

Likewise, the solution is as it was then, to delete all the files in the Decodes SQLite database folder.

Voila, Decodes immediately started right up and seemed to work even faster than before.

 

Quick Overview of This Problem and its Fix:

  1. PROBLEM: JT Alert Decodes program stores QSO messages displayed in an SQLite database
  2. The SQLite database that stores the Decodes messages gets corrupted.
    Corruption is likely due to an abnormal JT-Alert or Decodes process shutdown.
    E.g., during a JT-Alert  program freeze, one might have forcibly terminated it.
    Or, more likely, the Decodes sub-program hung due to internal database or memory issues.
  3. Once corrupted, Decodes sub-program can’t read QSO data nor write any new ones.
    The result of this is the oft-reported “Dead Decodes Window” problem.
  4. Restarted doesn’t help since the database is corrupt and no longer unusable.
  5. FIX: Delete the Decodes SQLite database data files. On next run, they will be recreated.
    Voila, it starts up and begins working as good (or maybe faster) than before.

How To Fix Steps:

Nb. Always exclude the double-quotes in examples below. They are for clarity, not entry.

 

  1. Exit out of JT-Alert If it is running

  2. Locate Decodes SQLite file  folder

The JT-Alert Decodes helper program maintains an SQLite database to store the Decodes messages.

This database is located in the “Local App Data” system area within a JT-Alert Decodes subtree.

 

For a typical Windows installation, the path to the Decodes SQLite database folder is as follows:

C:\Users\[username]\AppData\Local\HamApps\JTAlert\[CALL]\Decode

The “C:\Users\[username]\AppData\Local” portion is referred to as “LocalAppData”.

[username] is your Windows logon ID, such as Tom (mine), Dave, Hazel, Trixie or XYZ123.

Windows has a helpful “system macro” for that path, “%LocalAppData%” – it expands to the same thing.

 

Thus, you can set the File Explorer path to: %LOCALAPPDATA%\HamApps\JTAlert\[CALL]\Decode

Where “[CALL]” is your user call sign defined in JT-Alert, e.g, W1HUH

Once there, you’ll see the SQLite files as below (example uses my Windows name and call sign):

  1. Delete SQLite database files (or move them to temp folder for possible undoing).

The goal at this point is to remove all SQLite files (the ones in the GREEN rectangle).

This will force JT-Alert Decodes program to build a new/empty SQLite database structure.

You can simply delete them all (files only) and you are done. Just restart JT-Alert.

 

However, as an old hacker, I’m reticent to delete important objects until I know all is OK.

So, I created a temp folder to move them into (see RED rectangle). Name it as you like.

Next, select the files (NOT the folders) and move them into the temp folder you created.

That is, select all files (not folders) then Cut and paste them into the temp folder

E.g., Use Ctrl-X to Cut the selection, then Ctrl-V to Paste them into the temp folder.

At this point, there should only be folders that were there plus your new temp folder.

  1. Restart JL-Alert, open Decodes window and, voila, it should start logging QSOs.

  2. After all looks OK, you can return to the SQL folder and delete your temp folder.

 

Hope that helps anyone who was confused about how to execute this fix.

TomK / KT1TK / 73

As humans and AROs of Earth, our ethos must be to help all others – unless you are not!


locked Re: Ignored CallsignsNot Coloured

Tom Job
 

Hi Laurie….

 

Yes, the Ignored Callsign appears as it should if it is not B4.   I checked several random calls on 40m FT8 and it worked well.  Then I tried a couple that were B4 and it failed.

 

So, there ya go! J

 

73…..Tom

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: August 8, 2020 17:13
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Ignored CallsignsNot Coloured

 

On 8/08/2020 8:55 pm, Tom Job wrote:

Hi Laurie…

Yes, the alert is enabled under both Settings> Misc Alerts > Ignored Callsign   and also enabled under Settings>Alerts

I have already worked the station and it properly identified in the displayed calls as B4 (callsign – B4).   But, it didn’t show either the blue (default) Ignored Callsign background colour or the user-selected B4 background colour, which in my case is purple.  I know it won’t show both but it should show the default blue if it’s on the ignore list, I believe.  The background is always grey or grey with a green border if he’s calling CQ. 

The callsign also used to display in WSJT-X (2,2.2) as Ignored (blue) whenever it was decoded but that is not happening now, either.  It just displayed as green (CQ) or grey when in QSO.   Hmmm…

So, I totally removed the callsign from the ignored list, disabled both of the alerts (above) and rebuilt the alert databases.  Now it shows with the proper purple colour (B4) or purple with a green border for CQ in both JT Alert and WSJT-X. 

Then I reapplied the Ignored Callsign alert (both), with the callsign entered and rebuilt the alert database.  Unfortunately, it went back to the above situation, only grey background or grey with green border in JT Alert and no B4 indication in WSJT-X.

That’s what I’ve done to try to narrow the situation….I hope it helps.

73….Tom


Tom,

You only need to change the enabled state via the "Settings>Alerts" menu. The corresponding checkbox in the Settings window is automatically linked to the main gui menu.

Rebuilding the Alert database is not needed for ignored callsigns.

Question, does the ignored coloring get applied if the Callsign is not a B4? You can quickly test this by right-clicking any non-B4 callsign and adding it to the ignored list. It should then appear with the ignored coloring when next decoded. When next decoded a simple right-click and you can remove it from the ignored list without needing to open the Settings window.

de Laurie VK3AMA




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



locked Re: Logging confusion

HamApps Support (VK3AMA)
 

On 7/08/2020 5:45 am, John Holmes W9ILY wrote:
I am using standard ADIF logging with JTAlert and have a question regarding logging and the correct method. I use a non-integrated logging program, DX4WIN, and as a matter of course I manually import all of my FT8 ADIF files from WSXT-X and JTDX into that logging program, do a "full export" of that logging program periodically and indicate that "full export" file as my logging file that is read by JTAlert.  This has been working OK but I have just noticed that the standard ADIF files produced by WSJT-X and JTDX do not contain state and other miscellaneous info. JTAlert always attaches data from a newly contacted station including state, etc. and the "full" file then has that info. So far so good. However, I use DX4WIN for my general logging for all modes and the info that JTAlert has appended to my "full" file is overwritten the next time I export my FT8 QSOs into my DX4WIN program and create another "full" file to be read by JTAlert. Thus, newly contacted stations in wanted states is overwritten and literally gone. I am sure there is a workaround for this but I am a dead end. If JTAlert wrote the logging data to a new file I could simply import that file into my DX4WIN this creating a complete record of the QSO. But, I didn't see a way to do this . Any suggestions?
John W9ILY

John,

"I manually import all of my FT8 ADIF files from WSXT-X and JTDX into that logging program"
is the problem.

You need to be importing the ADIF file that JTAlert is updating when QSOs are logged as it contains the State, DXCC & Zone data which the 
WSJT-X/JTDX adif files lack. Importing the JTAlert updated adif file will then get new QSOs (with the extended data) into DX4WIN and should then be available in your next full export.

Currently your full export is missing data because your importing the minimal WSJT-X/JTDX files rather than the JTAlert file

de Laurie VK3AMA



locked Re: Ignored CallsignsNot Coloured

HamApps Support (VK3AMA)
 

On 8/08/2020 8:55 pm, Tom Job wrote:

Hi Laurie…

Yes, the alert is enabled under both Settings> Misc Alerts > Ignored Callsign   and also enabled under Settings>Alerts

I have already worked the station and it properly identified in the displayed calls as B4 (callsign – B4).   But, it didn’t show either the blue (default) Ignored Callsign background colour or the user-selected B4 background colour, which in my case is purple.  I know it won’t show both but it should show the default blue if it’s on the ignore list, I believe.  The background is always grey or grey with a green border if he’s calling CQ. 

The callsign also used to display in WSJT-X (2,2.2) as Ignored (blue) whenever it was decoded but that is not happening now, either.  It just displayed as green (CQ) or grey when in QSO.   Hmmm…

So, I totally removed the callsign from the ignored list, disabled both of the alerts (above) and rebuilt the alert databases.  Now it shows with the proper purple colour (B4) or purple with a green border for CQ in both JT Alert and WSJT-X. 

Then I reapplied the Ignored Callsign alert (both), with the callsign entered and rebuilt the alert database.  Unfortunately, it went back to the above situation, only grey background or grey with green border in JT Alert and no B4 indication in WSJT-X.

That’s what I’ve done to try to narrow the situation….I hope it helps.

73….Tom


Tom,

You only need to change the enabled state via the "Settings>Alerts" menu. The corresponding checkbox in the Settings window is automatically linked to the main gui menu.

Rebuilding the Alert database is not needed for ignored callsigns.

Question, does the ignored coloring get applied if the Callsign is not a B4? You can quickly test this by right-clicking any non-B4 callsign and adding it to the ignored list. It should then appear with the ignored coloring when next decoded. When next decoded a simple right-click and you can remove it from the ignored list without needing to open the Settings window.

de Laurie VK3AMA


locked Re: JTAlert does crash rem 2

HamApps Support (VK3AMA)
 

On 8/08/2020 8:48 pm, m_scot_alex wrote:
I normally run eight instances of WSJT-X and JTAlert without these, or any, errors and with much lower CPU load than mentioned above on an i7-3770S.


Here's my 4 instance data (using Process Explorer).
   
   

de Laurie VK3AMA


locked Re: JTAlert does crash rem 2

HamApps Support (VK3AMA)
 

On 8/08/2020 1:14 am, asobel@... wrote:
  1. Naturely, I did use FlexRadio 6xxx since the flex came here.
  2. Following your surprising advice I did try TS-2000 and PowerSDR. TS-2000 does seem to give the best results. The frequency of fail did decrease but did not stop.
  3. I figure out that the late upgrades in Win10, WSJT-X, JTAlert  and SmartSDR did increase CPU load. My CPU load does now peak at 90% with WSJT-X decode mode at “Deep”. Changing to “Normal” or “Fast” make it come to 80%. With some improovment in failure rate at the price of decode performance.
  4. Please look into JTAlert and try to find a way to decrease CPU load consumption.
  5. My computer is using Intel Core I7 4 core processor and 24GB RAM. Replacing processor means replacing the main board and RAM. Expensive!

 

Thanks for your help and the otherwise great JTAlert

 

Amos 4X4MF


Amos,

I am left thinking that the non-normal high CPU usage of JTAlert and the stalling of the program is due to an external influence. Likely your HRD Logbook. Are you using a MSAccess log?

In recent weeks/months a small number of JTAlert/HRD users have experienced JTAlert slowdowns and hangs that have been caused by problems with either their HRD
Log file or the ODBC settings for accessing the log. If this is the cause, it will be made worse when trying to access the log from multiple instances. Reading of the log for B4 checks is greatly increased when changing bands as previously cached B4 checks are discarded and have to be done again. Your experience of failures when changing bands suggests that the Log reading may be the cause.

The fix for HRD MSAccess log problems is to create a new log within HRDLogbook and set JTAlert to use that new log. Do the following...
  1. Stop all JTAlert instances.
  2. Do an adif export of your current HRD log.
  3. Create a NEW HRD log (this will create a new log file and a new ODBC connection).
  4. Import the adif file into your new log to restore your QSO data.
  5. Start ONE instance of JTAlert only.
  6. Open the JTAlert Settings and change the HRD "Log Name" to the new log you just created. eg.
  7. Close JTAlert
  8. Start your JTAlert instances and report back if performance has improved.

de Laurie VK3AMA


locked Re: 70cms on JTAlert

HamApps Support (VK3AMA)
 

On 8/08/2020 7:14 pm, Andrew G0MBL wrote:
Hi, now that the 6m Es season is over I'm planning on working 70cms for a while. It's disappointing that JTAlert doesn't support this band - any plans for it to be included in a future update? Great software otherwise though!

Andrew G0MBL

Andrew,

Adding additional bands to JTAlert is not a trivial task. It is very unlikely that a low-use band like 70cm will be added into the current JTAlertV2 series.

Having said that, the future JTAlertV3 (still many months from release), is not so restrictive, Bands supported will be 2200m -> 13cm. Here's a screen-grab of the Band Mode tracking selector from the JTAlertV3 settings, note the additional Bands and Modes.

   

de Laurie VK3AMA


locked Re: QSO database

HamApps Support (VK3AMA)
 

On 9/08/2020 3:23 am, Fabrizio Villanova - IK6GTF wrote:
i want to delete/modify the database that jtalert use to retain data of my qso's.
I have deleted some db files (hamapps_log.sqlite, B4logV2.mdb) but the B4LogV2 is recreated and populated as the program starts and all qso data is read from some other file as alerts work signaling new ones only.
The "clear B4 cache" don't works as worked station are shown with the B4 marker after the callsign.

Any help?

73
Fabrizio

All QSO data comes from your logger, that is the log you have enabled within JTAlert.

de Laurie VK3AMA


locked Re: AutoIT error; JTalert

HamApps Support (VK3AMA)
 

On 9/08/2020 3:27 am, Joe Roth wrote:
Did you receive my file? Any new ideas?

Yes I did and sent a reply.

The file sent was not the one I asked for. I wanted "JTAlertSettings.exe" which is located in the plugins directory.
Your previously posted error image indicated the problem was within
JTAlertSettings.exe

Rather than sending that file, please update JTAlert to the latest beta (check your email for the download link) and report back the line number shown in the error message when you try to open the Settings (I expect the problem will still be present within the latest build as it appears to be restricted to your PC environment only).

de Laurie VK3AMA


locked QSO database

Fabrizio Villanova - IK6GTF
 

Hi,
i want to delete/modify the database that jtalert use to retain data of my qso's.
I have deleted some db files (hamapps_log.sqlite, B4logV2.mdb) but the B4LogV2 is recreated and populated as the program starts and all qso data is read from some other file as alerts work signaling new ones only.
The "clear B4 cache" don't works as worked station are shown with the B4 marker after the callsign.

Any help?

73
Fabrizio


locked Re: AutoIT error; JTalert

Joe Roth
 

Did you receive my file? Any new ideas?


locked Re: 70cms on JTAlert

Dave Garber
 

Can you not add the frequency in the setup?

sent by my LG phone

On Sat, Aug 8, 2020, 12:44 PM Andrew G0MBL, <g0mbl@...> wrote:
Hi, now that the 6m Es season is over I'm planning on working 70cms for
a while. It's disappointing that JTAlert doesn't support this band - any
plans for it to be included in a future update? Great software otherwise
though!

Andrew G0MBL






locked 70cms on JTAlert

Andrew G0MBL
 

Hi, now that the 6m Es season is over I'm planning on working 70cms for a while. It's disappointing that JTAlert doesn't support this band - any plans for it to be included in a future update? Great software otherwise though!

Andrew G0MBL


locked Re: Ignored CallsignsNot Coloured

Tom Job
 

Hi Laurie…

 

Yes, the alert is enabled under both Settings> Misc Alerts > Ignored Callsign   and also enabled under Settings>Alerts

 

I have already worked the station and it properly identified in the displayed calls as B4 (callsign – B4).   But, it didn’t show either the blue (default) Ignored Callsign background colour or the user-selected B4 background colour, which in my case is purple.  I know it won’t show both but it should show the default blue if it’s on the ignore list, I believe.  The background is always grey or grey with a green border if he’s calling CQ. 

 

The callsign also used to display in WSJT-X (2,2.2) as Ignored (blue) whenever it was decoded but that is not happening now, either.  It just displayed as green (CQ) or grey when in QSO.   Hmmm…

 

So, I totally removed the callsign from the ignored list, disabled both of the alerts (above) and rebuilt the alert databases.  Now it shows with the proper purple colour (B4) or purple with a green border for CQ in both JT Alert and WSJT-X. 

 

Then I reapplied the Ignored Callsign alert (both), with the callsign entered and rebuilt the alert database.  Unfortunately, it went back to the above situation, only grey background or grey with green border in JT Alert and no B4 indication in WSJT-X.

 

That’s what I’ve done to try to narrow the situation….I hope it helps.

 

73….Tom

                                                                          

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: August 7, 2020 16:31
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Ignored CallsignsNot Coloured

 

On 7/08/2020 7:32 pm, Tom Job wrote:

I have upgraded to v2.16.10 and noticed that the callsign listed in my "Ignore Callsign" section of JTAlert are not displaying the default background colour, or any other selected colour.  I had it working fine in other version but this update seems to have killed the default background colour.  Ignored callsigns now appear with a grey background instead of the default or selected colour.  The Ignored Callsign colour used to show in the Band Activity window, too, of WSJT-X but it no longer does. 

I tried restarting the programs but no joy!

Using Windows 8.1 (updated), WSJT-X 2.2.2, JTAlert 2.10.16

Any help would be appreciated....Tom

Tom,

I can't fault the behavior in my tests. Do you have the Ignored Alert enabled?

de Laurie VK3AMA




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



locked Re: JTAlert does crash rem 2

m_scot_alex
 

I normally run eight instances of WSJT-X and JTAlert without these, or any, errors and with much lower CPU load than mentioned above on an i7-3770S.



I doubt the AutoIt error and WSJT-X rig control would be related under normal conditions but I would try not using rig control as a diagnostic. After corresponding with Bill G4WJS in the old Yahoo WSJT-X group, I don't use rig control with my 6700s and simply use VOX for keying the desired slice with no ill effect. Unless something has changed, WSJT-X rig control isn't designed for independent control of multiple SSDR slices and the developers have advised against trying to use it that way in the past.

73,

Mike - N8MSA


locked Re: Ignored CallsignsNot Coloured

HamApps Support (VK3AMA)
 

On 7/08/2020 7:32 pm, Tom Job wrote:
I have upgraded to v2.16.10 and noticed that the callsign listed in my "Ignore Callsign" section of JTAlert are not displaying the default background colour, or any other selected colour.  I had it working fine in other version but this update seems to have killed the default background colour.  Ignored callsigns now appear with a grey background instead of the default or selected colour.  The Ignored Callsign colour used to show in the Band Activity window, too, of WSJT-X but it no longer does. 

I tried restarting the programs but no joy!

Using Windows 8.1 (updated), WSJT-X 2.2.2, JTAlert 2.10.16

Any help would be appreciated....Tom
Tom,

I can't fault the behavior in my tests. Do you have the Ignored Alert enabled?

de Laurie VK3AMA


locked Re: Cannot select TX Watchdog - Defect Confirmed

HamApps Support (VK3AMA)
 

On 8/08/2020 1:43 am, WB5JJJ - George wrote:
I don't know when this started but in 2.16.10, I can't select under Miscellaneous Alerts >> TX Watchdog to change setting.
--
73's
George - WB5JJJ
George,

Tnx for the report. I can confirm this is a defect (introduced with 2.16.9), already corrected for the next release.

de Laurie VK3AMA



locked Re: Cannot select TX Watchdog

WB5JJJ - George
 

The fixed build works.  Thanks.
--
73's
George - WB5JJJ


locked Cannot select TX Watchdog

WB5JJJ - George
 
Edited

I don't know when this started but in 2.16.10, I can't select under Miscellaneous Alerts >> TX Watchdog to change setting.
--
73's
George - WB5JJJ


locked Re: JTAlert does crash rem 2

Michael Black
 

JTAlert shouldn't be using that much CPU power.  Most should be in PowerSDR and WSJT-X decoding.  JTAlert will be looking up callsigns during decoding so with 5 decodes going on things could get pretty busy.  Another thing is perhaps increase the priority on JTAlert since it's the one crashing.  You can use PowerHacker to do a lot with processes.

Try using rigctld from the latest hamlib here

Some changes were done as PowerSDR was taking too long on profile changes and some band changes.

So you can test the two Flex options pretty easily.

Just start rigctld like this

rigctld -m 2048
Or
rigctld -m 2036
Or
rigctld -m TS-2000 -r com1 -s 9600
Adjust baud and com port to suit.

Then set WSJT-X to use "Hamlib NET rigctl"

Let me know how these work.



On Friday, August 7, 2020, 10:14:58 AM CDT, asobel@... <asobel@...> wrote:


Mike

 

  1. Naturely, I did use FlexRadio 6xxx since the flex came here.
  2. Following your surprising advice I did try TS-2000 and PowerSDR. TS-2000 does seem to give the best results. The frequency of fail did decrease but did not stop.
  3. I figure out that the late upgrades in Win10, WSJT-X, JTAlert  and SmartSDR did increase CPU load. My CPU load does now peak at 90% with WSJT-X decode mode at “Deep”. Changing to “Normal” or “Fast” make it come to 80%. With some improovment in failure rate at the price of decode performance.
  4. Please look into JTAlert and try to find a way to decrease CPU load consumption.
  5. My computer is using Intel Core I7 4 core processor and 24GB RAM. Replacing processor means replacing the main board and RAM. Expensive!

 

Thanks for your help and the otherwise great JTAlert

 

Amos 4X4MF

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Michael Black via groups.io
Sent: Thursday, August 6, 2020 3:45 PM
To: support@hamapps.groups.io; Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert does crash rem 2

 

What rig have you chosen in WSJT-X?  There are 3 options for you.  Can you test each one?

The FlexRadio PowerSDR is relatively new.

 

#1 TS-2000

#2 FlexRadio 6xxx

#3 FlexRadio PowerSDR

 

Mike W9MDB

 

 

 

 

On Thursday, August 6, 2020, 03:53:43 AM CDT, asobel@... <asobel@...> wrote:

 

 

Laurie

 

Please look into this problem. It keeps me busy 50 times a day and does stop searching for DX without notice many times.

 

Amos 4X4MF

 

27/07/2020

Laurie

  1. There are two failure cases. See the attached snips. Case 1 is the result of Flex 6600 Profile change. Case 2 is random. If I change frequency by way of WSJT-X, no failure.
  2. My computer is using Intel I7 4.0 GHz and 24 GByte RAM. I did run memory tests which did show no failure.
  3. The failing instance does vary.
  4. Today, I did try to force failure with 1,2,3 instances, none. In the past, I did try working 3 instances for a long time and it did fail.

Thank you for your work and for helping us. JTAlert is what really makes my station go.

 

Amos 4X4MF

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Monday, July 27, 2020 5:39 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert does crash rem

 

On 26/07/2020 6:16 am, asobel@... wrote:

I am using Win10, Flex 6600 + SmartSDR, 4 instances of WSJTX-X + JTAlert. all of the latest verston.
Every time I change frequencies by way of SmartSDR, One or more instances of JTAlert does cresh.
I have to kill the task of the fallen alert and start it again.
This is very annoying. Please help.

Amos 4X4MF.


Does JTAlert show an error message? If so post an image.

Flex + SDR software can be very demanding on PC resources. Is you PC capable? How many CPU Cores, how much installed RAM?

Is the crashing JTAlert instance always the same instance or does it vary?

What happens if your restrict the number of instances to 3 only, do you still get the random crash?

de Laurie VK3AMA

5421 - 5440 of 36454