Date   

locked Re: JTAlert does crash rem 2

HamApps Support (VK3AMA)
 

On 10/08/2020 1:09 am, asobel@... wrote:
This morning, I did complete rebuilding my computer on an SSD disk. Unintentionally I did also rebuild the HRD Logbook using ADIF file backup similar to your description. 12 hours later, there was no fail. I hope it will stay so. Be sure, I will let you know if it fails

Good news!

de Laurie VK3AMA


locked Re: Logging confusion

HamApps Support (VK3AMA)
 

On 10/08/2020 12:55 am, John Holmes W9ILY wrote:
Thanks, Laurie. I figured that was the way to do it and glad you confirmed.
73,

John W9ILY
John,

FYI, A very near future JTAlert build utilizes a new ADIF file importer that is an improvement over the current importer, which as you know was a significant improvement over the old importer that took several minutes to process one of your large adif files.

The
current importer took ~18.6 secs (9.8K recs/sec) while the new importer took ~11.8 secs (15.5K recs/sec) to process one of your old 183K QSO files. That's a ~ 45% speed improvement!

Output window for current importer...
   

Output window for upcoming importer...
   


de Laurie VK3AMA


locked Re: Filtering Log for WAS after a date

HamApps Support (VK3AMA)
 

On 10/08/2020 3:49 am, D. Scott MacKenzie wrote:

Is there a way to filter the logs for needed states after a certain date? 

 

I moved to new QTH in 2000 and am trying for 5B WAS.  I need to filter the my alerts for states after 1/1/2000.  The DX needed filter can remain the same

 

Thanks

 

Scott aka KB0FHP


Scott,

Currently, only DXKeeper can provide what you want. The JTAlert "Rebuild Alert Database" operation (which scans your log) can consider QSOs that have one or more DXKeeper myQTH IDs defined. JTAlert can restrict the Alert Database rebuild to specific myQTH IDs on a per-Alert basis so you can have a myQTH restriction for States but no restriction for Dxcc as an example.

If your currently using DXKeeper and have suitable myQTH IDs set (and applied to your QSOs), visit the "Logging -> DXLab DXKeeper -> homeQTH Selections"" section of the JTAlert Settings window.

I note that the JTAlert Settings refer to "homeQTH" while DXKeeper refers to "myQTH" IDs. They are the same, it looks like there has been a name change sometime in the past and I need to account for (it has been several years since that area of JTAlert was first coded).

FYI, the future JTAlertV3 utilizes a more generic method of scanning the log, with a Date that can be explicitly set to restrict the Log scan. Each Alert type has an independent Date
setting. A screen-grab from the current JTAlertV3 Settings...
   

de Laurie VK3AMA


locked Re: AutoIT error; JTAlert - RESOLVED

HamApps Support (VK3AMA)
 

This defect has been resolved.

Joe WC4R, who experienced and reported this defect, has confirmed the latest JTAlert beta has corrected the problem. The next public release has the fix.

The cause was an obscure, non-critical, Windows permissions error that was not being captured and ignored, resulting in the JTAlert process being terminated.

de Laurie VK3AMA


locked Re: Would like to Add Propagation Mode and meteor shower to Logged QSO

Jim - N4ST
 

Maybe, I don't understand, but if you are running FT8 HF on one rig and MSK144 6M on a second rig, doesn’t the logged mode already tell you which is which?
Although logging a MSK144 QSO does not guarantee that the propagation mode was meteor scatter, but JTAlert wouldn't be capable of that distinction either.

_________
73,
Jim - N4ST

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of KD7YZ Bob
Sent: Sunday, August 9, 2020 08:46
To: Support@HamApps.groups.io
Subject: [HamApps] Would like to Add Propagation Mode and meteor shower to Logged QSO

I am running two rigs, usually.

At the moment I am on 6m Meteor Scatter. I am also running FT8 on 10m, or before daybreak, on 60m.

Thus there are two Propagation modes.
I'd like the settings 'retained' too.

Later on I like to see how I've been doping on MS so I sort DxKeeper for that mode.
For me, it's to fast between individual Band QSO's sometimes. So using DXKeeper 'Defaults' is a bit off base for my prestidigitation skills. Easier if the MS mode stays in the instance of JTAlert I am running while TR or some such stays in the HF FT8 instance of JTAlert running simultaneously.

thanks


Maybe it's too much trouble to add.
Just askin'






--
____________________
73,
Jim - N4ST


locked Filtering Log for WAS after a date

D. Scott MacKenzie
 

Hi all:

 

Is there a way to filter the logs for needed states after a certain date? 

 

I moved to new QTH in 2000 and am trying for 5B WAS.  I need to filter the my alerts for states after 1/1/2000.  The DX needed filter can remain the same

 

Thanks

 

Scott aka KB0FHP


locked Re: Is there a way to keep JTA always on top of all windows and resize the 8 pane to may 4 but double or triple

Román Toledo
 

thank you . that's much better  wish it was 4 slots and more lines , maybe next version .  but much better


locked Would like to Add Propagation Mode and meteor shower to Logged QSO

KD7YZ Bob
 

I am running two rigs, usually.

At the moment I am on 6m Meteor Scatter. I am also running FT8 on 10m, or before daybreak, on 60m.

Thus there are two Propagation modes.
I'd like the settings 'retained' too.

Later on I like to see how I've been doping on MS so I sort DxKeeper for that mode.
For me, it's to fast between individual Band QSO's sometimes. So using DXKeeper 'Defaults' is a bit off base for my prestidigitation skills. Easier if the MS mode stays in the instance of JTAlert I am running while TR or some such stays in the HF FT8 instance of JTAlert running simultaneously.

thanks


Maybe it's too much trouble to add.
Just askin'


locked Re: JTAlert does crash rem 2

asobel@...
 

Laurie

 

This morning, I did complete rebuilding my computer on an SSD disk. Unintentionally I did also rebuild the HRD Logbook using ADIF file backup similar to your description. 12 hours later, there was no fail. I hope it will stay so. Be sure, I will let you know if it fails

 

See below the CPU performance of my computer with SmartSDR, 4 instances of WSJT-X, 4 instances of JTAlert  , 1 HRD Logbook , Microsoft outlook and Win10 v2004. It does not peak 51%

 

Thanks for the most useful ham radio application!

 

Amos 4X4MF

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Sunday, August 9, 2020 12:01 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert does crash rem 2

 

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: Logging confusion

John Holmes W9ILY
 

Thanks, Laurie. I figured that was the way to do it and glad you confirmed.
73,

John W9ILY


locked Re: 70cms on JTAlert

Andrew G0MBL
 

Hi Laurie, well that is good news and something to look forward to! Many thanks, Andrew G0MBL


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

TomK
 

Argh!  I’ve been up way too long. Hit me with a nerf bat!

I missed your comment at the bottom stating the option does indeed delete the DB file entirely.

Which answered my last message.

My humble apologies!

 

My Counties question is still in play open, though 😊

TomK 73

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, August 8, 2020 10:27 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Decodes Windows Dead; Corrupt SQL DB; How To Fix

 

On 9/08/2020 9:24 am, TomK wrote:

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

TomK / KT1TK / 73


Tom,

FYI, a quicker solution (without the ability to save the old database) is to temporarily set the Decodes startup options to "Delete All Records" then restart (close & open) the Decodes window. Once restarted, you can change the options back to your previous setting.

   

Under-the-hood, this option will cause the the database file to be deleted and a new empty file to be created rather than trying to deleted all records from a possibly corrupt file.

de Laurie VK3AMA


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

TomK
 

Many thanks reply, Laurie, for your quick response.  I recall seeing that feature.

However, when the DB is corrupt, my thought was that brute force deletion avoids issues with Decodes program not being able to open and access the DB so as to issue a proper Delete Records command.

That then begs the question:

When the DB is corrupt, does “DELETE ALL RECORDS” delete the entire database structure to force a complete recreation of the DB?

If not, is Delete All Records option able to detect corruption and programmatically do what my Draconian method does?

I.e., Delete the entire structure and force a rebuild?

 

While I have you, good sir:

Q2: Will we ever see Counties added to the tracked objects?

My old hacker brain sees it as programmatically identical to all the other object trackers.

Plus, the usual weblogs you access providing the data like all the others.

It would be HIGHLY attractive to most users since it is one of the most active award credit pursuits.

I recall you once intimated (2 years ago), it was a targeted feature of the mythical v3 😊

 

Thanks for your time

I look forward to your responses.

Needless to say: Many Golden Kudos to you.

TomK / KT1TK / 73

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, August 8, 2020 10:27 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Decodes Windows Dead; Corrupt SQL DB; How To Fix

 

On 9/08/2020 9:24 am, TomK wrote:

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

TomK / KT1TK / 73


Tom,

FYI, a quicker solution (without the ability to save the old database) is to temporarily set the Decodes startup options to "Delete All Records" then restart (close & open) the Decodes window. Once restarted, you can change the options back to your previous setting.

   

Under-the-hood, this option will cause the the database file to be deleted and a new empty file to be created rather than trying to deleted all records from a possibly corrupt file.

de Laurie VK3AMA


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

HamApps Support (VK3AMA)
 

On 9/08/2020 9:24 am, TomK wrote:

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

TomK / KT1TK / 73


Tom,

FYI, a quicker solution (without the ability to save the old database) is to temporarily set the Decodes startup options to "Delete All Records" then restart (close & open) the Decodes window. Once restarted, you can change the options back to your previous setting.

   

Under-the-hood, this option will cause the the database file to be deleted and a new empty file to be created rather than trying to deleted all records from a possibly corrupt file.

de Laurie VK3AMA


locked Re: Is there a way to keep JTA always on top of all windows and resize the 8 pane to may 4 but double or triple

HamApps Support (VK3AMA)
 

On 9/08/2020 10:57 am, Román Toledo via groups.io wrote:
IS there a way to keep JTAlert always on top ?
    See the Settings window...
   


and can the window be resized so it's only 4 wide and the other 4 be under it, so I can be doing stuff and yet see when a QSO I am looking for comes up ?
    No, the width cannot be changed to 4 callsigns. You can add additional lines.
   

de Laurie VK3AMA


locked Is there a way to keep JTA always on top of all windows and resize the 8 pane to may 4 but double or triple

Román Toledo
 

IS there a way to keep JTAlert always on top ?

and can the window be resized so it's only 4 wide and the other 4 be under it, so I can be doing stuff and yet see when a QSO I am looking for comes up ?

you can reply here and to my email rtoledo2002  at yahoo   or rtoledo2  at gmail

thank you all


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

5861 - 5880 of 36910