locked Problems with JTAlert latest install


Jim Wysocki
 

I've been using JTAlert with WSJT-X for several years without any problems at all, until last night when I updated to version 2.50.3, 64 bit.  Several problems now have appeared.

There is a general sluggishness to JTAlert's main window.  In contrast to all of the others on the desktop, when this one is grabbed and moved around, there is a 1 or 2 second delay in its response.  The same is true of when it has focus and the mouse is scanned across the tabs from Alerts to Help.

The call signs windows that was immediately below the main window in the old version has disappeared, and pressing F3 will not make it show up.  The Decodes window can be made to appear by clicking on its option off of the View tab, but it has problems.  The decoded transactions that come to it from WSJT-X appear late and at intermittent times.  Every once in a while it will partially synch with WSJT-X, generally showing up to four of the latest callsigns that WSJT just decoded.  Occasionally JTAlert will grab more of them.  Most of the time it runs between one and six time slices behind WSJT.  Then it will grab about four of the latest transactions before locking up again.  It cannot respond in real time with the data feed from WSJT-X.

Here is some background information for the problem analysis.

I am running a fully-updated Windows 10 Professional (64-bit) machine, an i5 with four processors at around a 3.3 gig speed and 16 gb of memory.  Task manager shows no memory or processor bottlenecks.  Windows desktop Dotnet runtime version 5.0.7 64 bit has been installed without any problems.  The JTAlert Framework Check displayed the "Good News" screen at the time that version 2.50.3 was installed.

Both WSJT-X and JTAlert have been whitelisted on PCMatic SuperShield.  The Windows Defender firewall has been directed to allow the HamApps software apps to pass through it.  Just to make sure I've also disabled Defender from running on the computer's private network.

WSHJT's UDP server address is 127.0.0.1. Its UDP server port is 2237. Its secondary server is disabled.  The "Accept UDP addresses", "Notify on accepted UPD Request", and "Accept UDP Request Restores Window" options are all checked. 

On JTAlert, the Select menu's "WSJT-X  UDP Multicast on Loopback" option is checked.  In its Settings/Applications/WSJT-X / JTDX" section, all of the options are selected except for "Resend WSJT-X UDP Packets..." .  The value in the greyed-out IP address is 127.0.0.1, and the greyed-out UDP port's value is 2233.  None of these six checked options appears to control information in the Decodes screen.  As mentioned before, the Callsigns Window is no where to be seen.

Since this latest version was installed over the previous one, I used the Windows "Add or Remove Programs" utility to remove JTAlert, and then installed it again via

It appears to be that the transaction flow from WSJT and JTAlert is getting disrupted in some way, but I can't determine how this is happening.  I'm at a loss as to where to proceed from here so I need some advice.  What can be done next to diagnose and resolve this problem?

Thanks and 73,  Jim  W9FI



HamApps Support (VK3AMA)
 

On 14/07/2021 8:27 am, Jim Wysocki wrote:

I've been using JTAlert with WSJT-X for several years without any problems at all, until last night when I updated to version 2.50.3, 64 bit.  Several problems now have appeared.

There is a general sluggishness to JTAlert's main window.  In contrast to all of the others on the desktop, when this one is grabbed and moved around, there is a 1 or 2 second delay in its response.  The same is true of when it has focus and the mouse is scanned across the tabs from Alerts to Help.

The call signs windows that was immediately below the main window in the old version has disappeared, and pressing F3 will not make it show up.  The Decodes window can be made to appear by clicking on its option off of the View tab, but it has problems.  The decoded transactions that come to it from WSJT-X appear late and at intermittent times.  Every once in a while it will partially synch with WSJT-X, generally showing up to four of the latest callsigns that WSJT just decoded.  Occasionally JTAlert will grab more of them.  Most of the time it runs between one and six time slices behind WSJT.  Then it will grab about four of the latest transactions before locking up again.  It cannot respond in real time with the data feed from WSJT-X.

Here is some background information for the problem analysis.

I am running a fully-updated Windows 10 Professional (64-bit) machine, an i5 with four processors at around a 3.3 gig speed and 16 gb of memory.  Task manager shows no memory or processor bottlenecks.  Windows desktop Dotnet runtime version 5.0.7 64 bit has been installed without any problems.  The JTAlert Framework Check displayed the "Good News" screen at the time that version 2.50.3 was installed.

Both WSJT-X and JTAlert have been whitelisted on PCMatic SuperShield.  The Windows Defender firewall has been directed to allow the HamApps software apps to pass through it.  Just to make sure I've also disabled Defender from running on the computer's private network.

WSHJT's UDP server address is 127.0.0.1. Its UDP server port is 2237. Its secondary server is disabled.  The "Accept UDP addresses", "Notify on accepted UPD Request", and "Accept UDP Request Restores Window" options are all checked. 

On JTAlert, the Select menu's "WSJT-X  UDP Multicast on Loopback" option is checked.  In its Settings/Applications/WSJT-X / JTDX" section, all of the options are selected except for "Resend WSJT-X UDP Packets..." .  The value in the greyed-out IP address is 127.0.0.1, and the greyed-out UDP port's value is 2233.  None of these six checked options appears to control information in the Decodes screen.  As mentioned before, the Callsigns Window is no where to be seen.

Since this latest version was installed over the previous one, I used the Windows "Add or Remove Programs" utility to remove JTAlert, and then installed it again via

It appears to be that the transaction flow from WSJT and JTAlert is getting disrupted in some way, but I can't determine how this is happening.  I'm at a loss as to where to proceed from here so I need some advice.  What can be done next to diagnose and resolve this problem?

Thanks and 73,  Jim  W9FI


Jim,

Thanks for the detailed message. You have answered some of the questions I would have asked. Thanks for making the effort to read the group messages and attempt diagnosis before posting.

What is the CPU usage of JTAlert when it is sluggish or non-responsive?

Have you done a PC restart?

I note you said the "The call signs windows that was immediately below the main window in the old version has disappeared". That is correct, that display was retired when JTAlert 2.50.0 was released as it includes a standalone resizable no callsign display limit window called the "Callsigns" window.

Since you asked about the old inbuilt callsign display suggests that you upgraded from a pre 2.50.x release of JTAlert. Is that the case? If so what version were you running before the 2.50.3 install?

de Laurie VK3AMA



Joe Subich, W4TV
 

WSHJT's UDP server address is 127.0.0.1. Its UDP server port is 2237.
Its secondary server is disabled. The "Accept UDP addresses", "Notify
on accepted UPD Request", and "Accept UDP Request Restores Window"
options are all checked.

On JTAlert, the Select menu's "WSJT-X UDP Multicast on Loopback"
option is checked. In its Settings/Applications/WSJT-X / JTDX"
section, all of the options are selected except for "Resend WSJT-X
UDP Packets..."
If you are using multicast ("WSJTX UDP Multicast on Loopback" checked),
you need to use a Multicast address in WSJTX -> Settings -> Reporting ->
Network Services. See: Help -> WSJT-X UDP Setup in JTAlert.

Multicast address ranges are: 224.0.0.1 to 224.0.0.255 and
239.255.0.1 to 239.255.255.255. The recommended address is
224.0.0.1

73,

... Joe, W4TV


On 2021-07-13 6:27 PM, Jim Wysocki wrote:
I've been using JTAlert with WSJT-X for several years without any problems at all, until last night when I updated to version 2.50.3, 64 bit.  Several problems now have appeared.
There is a general sluggishness to JTAlert's main window.  In contrast to all of the others on the desktop, when this one is grabbed and moved around, there is a 1 or 2 second delay in its response.  The same is true of when it has focus and the mouse is scanned across the tabs from Alerts to Help.
The call signs windows that was immediately below the main window in the old version has disappeared, and pressing F3 will not make it show up. The Decodes window can be made to appear by clicking on its option off of the View tab, but it has problems.  The decoded transactions that come to it from WSJT-X appear late and at intermittent times.  Every once in a while it will partially synch with WSJT-X, generally showing up to four of the latest callsigns that WSJT just decoded.  Occasionally JTAlert will grab more of them.  Most of the time it runs between one and six time slices behind WSJT.  Then it will grab about four of the latest transactions before locking up again. It cannot respond in real time with the data feed from WSJT-X.
Here is some background information for the problem analysis.
I am running a fully-updated Windows 10 Professional (64-bit) machine, an i5 with four processors at around a 3.3 gig speed and 16 gb of memory.  Task manager shows no memory or processor bottlenecks.  Windows desktop Dotnet runtime version 5.0.7 64 bit has been installed without any problems.  The JTAlert Framework Check displayed the "Good News" screen at the time that version 2.50.3 was installed.
Both WSJT-X and JTAlert have been whitelisted on PCMatic SuperShield. The Windows Defender firewall has been directed to allow the HamApps software apps to pass through it. Just to make sure I've also disabled Defender from running on the computer's private network.
WSHJT's UDP server address is 127.0.0.1. Its UDP server port is 2237. Its secondary server is disabled.  The "Accept UDP addresses", "Notify on accepted UPD Request", and "Accept UDP Request Restores Window" options are all checked.
On JTAlert, the Select menu's "WSJT-X  UDP Multicast on Loopback" option is checked.  In its Settings/Applications/WSJT-X / JTDX" section, all of the options are selected except for "Resend WSJT-X UDP Packets..." . The value in the greyed-out IP address is 127.0.0.1, and the greyed-out UDP port's value is 2233.  None of these six checked options appears to control information in the Decodes screen. As mentioned before, the Callsigns Window is no where to be seen.
Since this latest version was installed over the previous one, I used the Windows "Add or Remove Programs" utility to remove JTAlert, and then installed it again via
It appears to be that the transaction flow from WSJT and JTAlert is getting disrupted in some way, but I can't determine how this is happening.  I'm at a loss as to where to proceed from here so I need some advice.  What can be done next to diagnose and resolve this problem?
Thanks and 73,  Jim  W9FI


HamApps Support (VK3AMA)
 

On 14/07/2021 9:34 am, Joe Subich, W4TV wrote:
If you are using multicast ("WSJTX UDP Multicast on Loopback" checked),
you need to use a Multicast address in WSJTX -> Settings -> Reporting ->
Network Services.  See: Help -> WSJT-X UDP Setup in JTAlert.

Joe,

That is not the case. The "multicast on loopback" setting can be left enabled when running unicast WSJT-X.
JTAlert ignores the setting if WSJT-X is detected not running multicast.

de Laurie VK3AMA



Jim Wysocki
 

Thanks for the quick response.  Here are the answers to your questions.

The CPU usage never topped 24%, with most of the load coming from WSJT-X's decoding engine at 12% -14%.  JTAlert's usage typically never rose about 1.5%.  In terms of memory, everything running on the computer only brought the memory percentage above a few percent.  Memory usage never got above the single digits.

I did two PC restarts to see what would happen.  There was no change in JTAlert's behavior, from before to after the restarts.

Thanks for the explanation of the user interface redesign and the replacement of the old call signs window with the stand alone, resizable one.  I presume that it's different from the Decodes window.  I've seen "Decodes" but not "Call Signs".  Hopefully that situation will change soon.

I was running version 2.16.14 before the 2.50.3 install.

I hope these clues help in the problem solving process.

73,  Jim  W9FI


On 7/13/2021 4:31 PM, HamApps Support (VK3AMA) wrote:
On 14/07/2021 8:27 am, Jim Wysocki wrote:

I've been using JTAlert with WSJT-X for several years without any problems at all, until last night when I updated to version 2.50.3, 64 bit.  Several problems now have appeared.

There is a general sluggishness to JTAlert's main window.  In contrast to all of the others on the desktop, when this one is grabbed and moved around, there is a 1 or 2 second delay in its response.  The same is true of when it has focus and the mouse is scanned across the tabs from Alerts to Help.

The call signs windows that was immediately below the main window in the old version has disappeared, and pressing F3 will not make it show up.  The Decodes window can be made to appear by clicking on its option off of the View tab, but it has problems.  The decoded transactions that come to it from WSJT-X appear late and at intermittent times.  Every once in a while it will partially synch with WSJT-X, generally showing up to four of the latest callsigns that WSJT just decoded.  Occasionally JTAlert will grab more of them.  Most of the time it runs between one and six time slices behind WSJT.  Then it will grab about four of the latest transactions before locking up again.  It cannot respond in real time with the data feed from WSJT-X.

Here is some background information for the problem analysis.

I am running a fully-updated Windows 10 Professional (64-bit) machine, an i5 with four processors at around a 3.3 gig speed and 16 gb of memory.  Task manager shows no memory or processor bottlenecks.  Windows desktop Dotnet runtime version 5.0.7 64 bit has been installed without any problems.  The JTAlert Framework Check displayed the "Good News" screen at the time that version 2.50.3 was installed.

Both WSJT-X and JTAlert have been whitelisted on PCMatic SuperShield.  The Windows Defender firewall has been directed to allow the HamApps software apps to pass through it.  Just to make sure I've also disabled Defender from running on the computer's private network.

WSHJT's UDP server address is 127.0.0.1. Its UDP server port is 2237. Its secondary server is disabled.  The "Accept UDP addresses", "Notify on accepted UPD Request", and "Accept UDP Request Restores Window" options are all checked. 

On JTAlert, the Select menu's "WSJT-X  UDP Multicast on Loopback" option is checked.  In its Settings/Applications/WSJT-X / JTDX" section, all of the options are selected except for "Resend WSJT-X UDP Packets..." .  The value in the greyed-out IP address is 127.0.0.1, and the greyed-out UDP port's value is 2233.  None of these six checked options appears to control information in the Decodes screen.  As mentioned before, the Callsigns Window is no where to be seen.

Since this latest version was installed over the previous one, I used the Windows "Add or Remove Programs" utility to remove JTAlert, and then installed it again via

It appears to be that the transaction flow from WSJT and JTAlert is getting disrupted in some way, but I can't determine how this is happening.  I'm at a loss as to where to proceed from here so I need some advice.  What can be done next to diagnose and resolve this problem?

Thanks and 73,  Jim  W9FI


Jim,

Thanks for the detailed message. You have answered some of the questions I would have asked. Thanks for making the effort to read the group messages and attempt diagnosis before posting.

What is the CPU usage of JTAlert when it is sluggish or non-responsive?

Have you done a PC restart?

I note you said the "The call signs windows that was immediately below the main window in the old version has disappeared". That is correct, that display was retired when JTAlert 2.50.0 was released as it includes a standalone resizable no callsign display limit window called the "Callsigns" window.

Since you asked about the old inbuilt callsign display suggests that you upgraded from a pre 2.50.x release of JTAlert. Is that the case? If so what version were you running before the 2.50.3 install?

de Laurie VK3AMA



Jim Wysocki
 

Thanks for your reply, Joe, and hello again on a different forum.

I tried changing the UDP address to 224.0.0.1 without success, but that was before I turned off Windows Defender and got it out of the way.  I'll change the UDP address accordingly and report back tomorrow on the results.  The reconfiguration will have to wait until the morning because the local weather won't cooperate with the testing process.  It's  going to be an active night of continuing rain, lightning and thunder.  The station has been disconnected until the WX clears up early tomorrow morning.

73,  Jim  W9FI

On 7/13/2021 4:34 PM, Joe Subich, W4TV wrote:

> WSHJT's UDP server address is 127.0.0.1. Its UDP server port is 2237.
> Its secondary server is disabled.  The "Accept UDP addresses", "Notify
> on accepted UPD Request", and "Accept UDP Request Restores Window"
> options are all checked.
>
On JTAlert, the Select menu's "WSJT-X  UDP Multicast on Loopback"
option is checked.  In its Settings/Applications/WSJT-X / JTDX"
section, all of the options are selected except for "Resend WSJT-X
UDP Packets..."

If you are using multicast ("WSJTX UDP Multicast on Loopback" checked),
you need to use a Multicast address in WSJTX -> Settings -> Reporting ->
Network Services.  See: Help -> WSJT-X UDP Setup in JTAlert.

Multicast address ranges are: 224.0.0.1 to 224.0.0.255  and
239.255.0.1 to 239.255.255.255.  The recommended address is
224.0.0.1

73,

   ... Joe, W4TV


On 2021-07-13 6:27 PM, Jim Wysocki wrote:
I've been using JTAlert with WSJT-X for several years without any problems at all, until last night when I updated to version 2.50.3, 64 bit.  Several problems now have appeared.

There is a general sluggishness to JTAlert's main window.  In contrast to all of the others on the desktop, when this one is grabbed and moved around, there is a 1 or 2 second delay in its response.  The same is true of when it has focus and the mouse is scanned across the tabs from Alerts to Help.

The call signs windows that was immediately below the main window in the old version has disappeared, and pressing F3 will not make it show up. The Decodes window can be made to appear by clicking on its option off of the View tab, but it has problems.  The decoded transactions that come to it from WSJT-X appear late and at intermittent times.  Every once in a while it will partially synch with WSJT-X, generally showing up to four of the latest callsigns that WSJT just decoded.  Occasionally JTAlert will grab more of them.  Most of the time it runs between one and six time slices behind WSJT.  Then it will grab about four of the latest transactions before locking up again. It cannot respond in real time with the data feed from WSJT-X.

Here is some background information for the problem analysis.

I am running a fully-updated Windows 10 Professional (64-bit) machine, an i5 with four processors at around a 3.3 gig speed and 16 gb of memory.  Task manager shows no memory or processor bottlenecks.  Windows desktop Dotnet runtime version 5.0.7 64 bit has been installed without any problems.  The JTAlert Framework Check displayed the "Good News" screen at the time that version 2.50.3 was installed.

Both WSJT-X and JTAlert have been whitelisted on PCMatic SuperShield. The Windows Defender firewall has been directed to allow the HamApps software apps to pass through it. Just to make sure I've also disabled Defender from running on the computer's private network.

WSHJT's UDP server address is 127.0.0.1. Its UDP server port is 2237. Its secondary server is disabled.  The "Accept UDP addresses", "Notify on accepted UPD Request", and "Accept UDP Request Restores Window" options are all checked.

On JTAlert, the Select menu's "WSJT-X  UDP Multicast on Loopback" option is checked.  In its Settings/Applications/WSJT-X / JTDX" section, all of the options are selected except for "Resend WSJT-X UDP Packets..." . The value in the greyed-out IP address is 127.0.0.1, and the greyed-out UDP port's value is 2233.  None of these six checked options appears to control information in the Decodes screen. As mentioned before, the Callsigns Window is no where to be seen.

Since this latest version was installed over the previous one, I used the Windows "Add or Remove Programs" utility to remove JTAlert, and then installed it again via

It appears to be that the transaction flow from WSJT and JTAlert is getting disrupted in some way, but I can't determine how this is happening.  I'm at a loss as to where to proceed from here so I need some advice.  What can be done next to diagnose and resolve this problem?

Thanks and 73,  Jim  W9FI










Jim Wysocki
 

I'll hold off on making this change and instead see how version 2.50.2 behaves.

Jim  W9FI

On 7/13/2021 4:49 PM, HamApps Support (VK3AMA) wrote:
On 14/07/2021 9:34 am, Joe Subich, W4TV wrote:
If you are using multicast ("WSJTX UDP Multicast on Loopback" checked),
you need to use a Multicast address in WSJTX -> Settings -> Reporting ->
Network Services.  See: Help -> WSJT-X UDP Setup in JTAlert.

Joe,

That is not the case. The "multicast on loopback" setting can be left enabled when running unicast WSJT-X.
JTAlert ignores the setting if WSJT-X is detected not running multicast.

de Laurie VK3AMA



Jim Wysocki
 

Laurie, here's one more item that was buried in my notes to myself.  Task Manager saw that HamApps "Decoder" was running consistently, but that HamApps "Audio and Visual Alerts for WSJT-X (32 bit)" was appearing and disappearing from the its list of active apps.  Audio and Visual Alerts ran on a consistent cycle, at about 3 seconds on and 3 seconds off, repeatedly.

Maybe this is typical behavior or not; I can't tell but you'll know the answer.

73,  Jim  W9FI

On 7/13/2021 6:18 PM, Jim Wysocki wrote:

I'll hold off on making this change and instead see how version 2.50.2 behaves.

Jim  W9FI

On 7/13/2021 4:49 PM, HamApps Support (VK3AMA) wrote:
On 14/07/2021 9:34 am, Joe Subich, W4TV wrote:
If you are using multicast ("WSJTX UDP Multicast on Loopback" checked),
you need to use a Multicast address in WSJTX -> Settings -> Reporting ->
Network Services.  See: Help -> WSJT-X UDP Setup in JTAlert.

Joe,

That is not the case. The "multicast on loopback" setting can be left enabled when running unicast WSJT-X.
JTAlert ignores the setting if WSJT-X is detected not running multicast.

de Laurie VK3AMA



HamApps Support (VK3AMA)
 

On 14/07/2021 10:55 am, Jim Wysocki wrote:

I've seen "Decodes" but not "Call Signs".  Hopefully that situation will change soon.

I was running version 2.16.14 before the 2.50.3 install.

I hope these clues help in the problem solving process.

73,  Jim  W9FI


The Decodes window, which BTW is currently being rewritten, uses the old .NET Framework runtime technology. The Callsigns window, which is part of the JTAlertV2.Manager uses the newer .NET (formally .NET Core) Desktop Runtime.

My guess is that the Manager process is faulting which will cause most of the JTAlert functionality to cease working, including opening any of the "yellow stared" windows under the View menu.

Please check the Windows Event Viewer and see if there are any errors recorded there.
eg. this is from my test PC where I have deliberately installed the wrong NET Desktop Runtime causing the Manager process to fault.

   

Let me know what you find.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 14/07/2021 11:45 am, Jim Wysocki wrote:

udio and Visual Alerts ran on a consistent cycle, at about 3 seconds on and 3 seconds off, repeatedly.

Maybe this is typical behavior or not; I can't tell but you'll know the answer.

73,  Jim  W9FI


No, not normal behavior. That indicates that the Manager is faulting and JTAlert is restarting it. 3 seconds sounds about right as the process is not faulting immediately and JTAlert will likely not see that it has gone AWOL as it only polls every 2 seconds.

Both JTAlert.exe and JTAlertV2.Manager.exe should run continuously.

See my other response here.

de Laurie VK3AMA


rsagun
 

I had the same problems as Jim W9FI.  I did several restarts and was upgrading from 2.50.2.  No success.  Also I noticed that sound wasn't working either.

Thanks,

Ross W6RSS


Jim Wysocki
 

I backed up the event log and then erased it, so that I could get a fresh start on the current events.  Then I started up WSJT-X and JTAlert.  JTAlert behaved exactly the same as it did last night, with occasional WSJT transactions being displayed.  I then terminated both apps and went to event log.  There were no errors but plenty of warning messages displayed.  They all were generated by PCMatic, showing the following.

This was displayed in the Event Properties screen's General tab.  It's the "Friendly" view.

"The system cannot find the file specified."

That's a direct paste from the tab.  This was displayed in the Details tab.

"User allowed unknown application at: c:\program files (x86)\hamapps\jtalert\pluginsx\jtalertv2.manager.exe"

Here's the XML Event view of that message.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="pcmatic" />
  <EventID Qualifiers="0">2</EventID>
  <Version>0</Version>
  <Level>3</Level>
  <Task>1</Task>
  <Opcode>0</Opcode>
  <Keywords>0x80000000000000</Keywords>
  <TimeCreated SystemTime="2021-07-14T17:34:28.8931806Z" />
  <EventRecordID>46806</EventRecordID>
  <Correlation />
  <Execution ProcessID="0" ThreadID="0" />
  <Channel>Application</Channel>
  <Computer>CBAWorkstation</Computer>
  <Security />
  </System>
- <EventData>
  <Data>User allowed unknown application at: c:\program files (x86)\hamapps\jtalert\pluginsx\jtalertv2.manager.exe</Data>
  </EventData>
  </Event>

The very first warning messages were to note the opening of several modules of the DXLab suite, and other related software apps like DXAtlas.  The warning message only appeared once for each of them.  The event log then noted the opening of wsjtx.exe and jt9.exe.  This was followed by one instance of JTAlert.exe opening and then jtalertv2manager.exe.  This was followed by the opening of jtalertv2.decodes.exe, and the reopening of jtalertv2.manager.exe.   After that it was followed by what appeared to be an infinite loop of jtalertv2.manager.exe reopenings.  I closed all of these programs after a couple of minutes.  The system clock indicated a repeated pattern of jtalertv2.manager.exe reopening after 5 or 6 seconds.

I hope these clues were instructive.  Now I'm going to uninstall NET 5.0.7 and replace it with 5.0.8.  I'll report back with the test results.

73,  Jim  W9FI

On 7/14/2021 2:34 AM, HamApps Support (VK3AMA) wrote:
On 14/07/2021 11:45 am, Jim Wysocki wrote:

udio and Visual Alerts ran on a consistent cycle, at about 3 seconds on and 3 seconds off, repeatedly.

Maybe this is typical behavior or not; I can't tell but you'll know the answer.

73,  Jim  W9FI


No, not normal behavior. That indicates that the Manager is faulting and JTAlert is restarting it. 3 seconds sounds about right as the process is not faulting immediately and JTAlert will likely not see that it has gone AWOL as it only polls every 2 seconds.

Both JTAlert.exe and JTAlertV2.Manager.exe should run continuously.

See my other response here.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 15/07/2021 4:09 am, Jim Wysocki wrote:

After that it was followed by what appeared to be an infinite loop of jtalertv2.manager.exe reopenings.  I closed all of these programs after a couple of minutes.  The system clock indicated a repeated pattern of jtalertv2.manager.exe reopening after 5 or 6 seconds.

I hope these clues were instructive.  Now I'm going to uninstall NET 5.0.7 and replace it with 5.0.8.  I'll report back with the test results.

73,  Jim  W9FI


Jim,

Perhaps pcmatic is interfering with this new release of JTAlert?

The repeated looping is JTAlert.exe process restarting JTAlertV2.Manager.exe process. The Manger faulting is the problem.  The Manager faulting is typically caused when running JTAlert 2.50.1 or earlier against NET 5.0.7 caused by a defect in 5.0.7 or when running JTAlert against an incompatible NET runtime. There may be other issues that I am unaware of causing the Manager to fault.

Is there anything in your Event logs pertaining to errors thrown by JTAlertV2.Manager.exe specifically?

if you don't mind, could you zip up your HamApps directory located under $localappdata% and put it up on dropbox or similar? If you can do that please email me directly (vk3ama.ham.apps [at] gmail.com) the download link. Thanks

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 15/07/2021 4:40 am, HamApps Support (VK3AMA) via groups.io wrote:
zip up your HamApps directory located under $localappdata%

that should be %localappdata%

de Laurie VK3AMA


Jim Wysocki
 

I installed .NET 5.0.8 and there was no change in JTAlert's behavior.  Same symptoms.  Now I'm going to uninstall version 2.50.3 and replace it with version 2.50.2.  Test results will follow.

Jim  W9FI

On 7/14/2021 11:09 AM, Jim Wysocki wrote:
... The system clock indicated a repeated pattern of jtalertv2.manager.exe reopening after 5 or 6 seconds.

I hope these clues were instructive.  Now I'm going to uninstall NET 5.0.7 and replace it with 5.0.8.  I'll report back with the test results.

73,  Jim  W9FI



Laurie, VK3AMA
 

On 15/07/2021 4:47 am, Jim Wysocki wrote:

I installed .NET 5.0.8 and there was no change in JTAlert's behavior.  Same symptoms.  Now I'm going to uninstall version 2.50.3 and replace it with version 2.50.2.  Test results will follow.

Jim  W9FI
What is event viewer showing with respect to the JTALertV2.Manager.exe faulting?

Have you tried disabling pcmatic, it could be interferring. I note it was mentioned explicitly in your posted event xml for JTAlertV2.Manager.exe

de Laurie VK3AMA


Jim Wysocki
 

JTAlert is whitelisted, so PCMatic stays out of its way.  Those warnings are just timestamped notes that an app on the exception list passed by.

There is nothing on Event Viewer for any HamApps application.  All of the other activity was from MSInstaller, updating .NET.

Yes, I'll zip up the directory and email it to you.

Jim  W9FI

On 7/14/2021 11:40 AM, HamApps Support (VK3AMA) wrote:
On 15/07/2021 4:09 am, Jim Wysocki wrote:

After that it was followed by what appeared to be an infinite loop of jtalertv2.manager.exe reopenings.  I closed all of these programs after a couple of minutes.  The system clock indicated a repeated pattern of jtalertv2.manager.exe reopening after 5 or 6 seconds.

I hope these clues were instructive.  Now I'm going to uninstall NET 5.0.7 and replace it with 5.0.8.  I'll report back with the test results.

73,  Jim  W9FI


Jim,

Perhaps pcmatic is interfering with this new release of JTAlert?

The repeated looping is JTAlert.exe process restarting JTAlertV2.Manager.exe process. The Manger faulting is the problem.  The Manager faulting is typically caused when running JTAlert 2.50.1 or earlier against NET 5.0.7 caused by a defect in 5.0.7 or when running JTAlert against an incompatible NET runtime. There may be other issues that I am unaware of causing the Manager to fault.

Is there anything in your Event logs pertaining to errors thrown by JTAlertV2.Manager.exe specifically?

if you don't mind, could you zip up your HamApps directory located under $localappdata% and put it up on dropbox or similar? If you can do that please email me directly (vk3ama.ham.apps [at] gmail.com) the download link. Thanks

de Laurie VK3AMA


Jim Wysocki
 

Correction noted.

On 7/14/2021 11:43 AM, HamApps Support (VK3AMA) wrote:
On 15/07/2021 4:40 am, HamApps Support (VK3AMA) via groups.io wrote:
zip up your HamApps directory located under $localappdata%

that should be %localappdata%

de Laurie VK3AMA


Laurie, VK3AMA
 



On 15/07/2021 5:35 am, Jim Wysocki wrote:

JTAlert is whitelisted, so PCMatic stays out of its way.  Those warnings are just timestamped notes that an app on the exception list passed by.

There is nothing on Event Viewer for any HamApps application.  All of the other activity was from MSInstaller, updating .NET.

Yes, I'll zip up the directory and email it to you.

Jim  W9FI


Tnx Jim,

Something to try...
  • With a failing JTAlert 2.50.3 install
  • stop JTAlert then delete any files starting with "Callsigns_" in the %localappdata%\HamApps\JTAlert\<your_callsign>\Config\ directory. When using a single JTAlert instance there will be 2 files "Callsigns_1.config" & "Callsigns_1.config.json".
  • Then start JTAlert.
  • Are you able to now bring up the different "yellow stared" windows under the "View" menu of the main JTAlert window?

de Laurie VK3AMA



Bill Stott W4XK
 

I installed the new version of JTAlert recently and had most of the problems that had been mentioned. Inability to open windows
from the view list, very sluggish responses, sound problems, etc. I rolled back to 2.50.2 and everything was back to normal. Then
today I followed Laurie's advice to uninstall the older version, make sure you were using .net and JTAlert 64 bit versions and then
install the latest JTAlert version. The new version is running flawlessly and I have had no problems, at least with the functions and
windows that I normally use and others that I have tried. This on a machine running Windows 10 home edition, updated with all
the latest updates, 64 bit OS. Try it, you'll like it!

Bill  W4XK