Topics

locked JTAlert does crash rem 2


asobel@...
 

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


Michael Black
 

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


asobel@...
 

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


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


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


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


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


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


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