Date   

locked Re: Sound Not Working in 2.15.4

Barry Murrell ZS2EZ
 

Hi Hasan

 

Whilst my Realtek card happens to be the Default Sound Card, it was selected in JTAlert by it’s name (REALTEK SPEAKERS (High Definition)

 

Works perfectly in 2.15.3 ….. I NEVER select Windows Default Sound Card, as I have 6 sound devices (plus a virtual audio cable) set up on my PC!

 

73 de BARRY MURRELL ZS2EZ

KF26ta - Port Elizabeth, South Africa

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Hasan Schiers N0AN
Sent: Thursday, 05 December 2019 12:11
To: Support <Support@hamapps.groups.io>
Subject: Re: [HamApps] Sound Not Working in 2.15.4

 

It says right in the release notes that the Windows Default Sound Card will no longer work, period. You have to use a named sound card. Read the release notes. (If I understand your problem)

73, N0AN

Hasan

 

 

On Wed, Dec 4, 2019 at 11:24 PM Barry Murrell ZS2EZ <mailgroups@...> wrote:

Hi Laurie

 

Installed the new 2.15.4 version – sound stopped working. Reverted back to 2.15.3 – works perfectly.

 

I use the onboard Realtek sound card for my alerts/system sounds etc – it is the Windows Default sound card, but is selected by name in JTAlert.

 

Before reverting back I tried restarting the PC, to no avail. Running Windows 10 64 Bit (1909 update), 16Gb RAM, JTDX 2.1.0-rc144 and logging to DXKeeper.

 

73 de BARRY MURRELL ZS2EZ

KF26ta - Port Elizabeth, South Africa

EPC#0558 DMC#1690  30MDG#4081

DXCC HONOR ROLL (332/340)

DXCC(mixed)#41,146  DXCC(RTTY)#1,916

DXCC(phone)#34,990  DXCC(CW)#11,714

DXCC 80m,40m,30m,20m,17m,15m,12m,10m   5BDXCC#8,916

WAS Triple Play #492  WAS(RTTY)#538  WAS(Digital)#163-Endorsements JT65,FT8

WAZ(RTTY)#185  WAE-I(mixed)#72  WAZS(mixed)#214  AAA#1569

AS ZR6DXB: VUCC(50MHZ)#1,334  UKSMG WAE(Silver)#75  UKSMG AFRICA#22  WAC (Satellite)

website : www.zs2ez.co.za

 

 


locked Re: V2.15.3 No access to menus, not possibloe to close program without Task Manager

Frode Igland
 

Thanks to Mike and Laurie. Among my many icons, I didn't even notice the green icon. Once I found, all worked just fine. Always good to climb the learning ladder.

Frode LA6VQ


locked Re: Sound Not Working in 2.15.4

Hasan Schiers N0AN
 

It says right in the release notes that the Windows Default Sound Card will no longer work, period. You have to use a named sound card. Read the release notes. (If I understand your problem)
73, N0AN
Hasan


On Wed, Dec 4, 2019 at 11:24 PM Barry Murrell ZS2EZ <mailgroups@...> wrote:

Hi Laurie

 

Installed the new 2.15.4 version – sound stopped working. Reverted back to 2.15.3 – works perfectly.

 

I use the onboard Realtek sound card for my alerts/system sounds etc – it is the Windows Default sound card, but is selected by name in JTAlert.

 

Before reverting back I tried restarting the PC, to no avail. Running Windows 10 64 Bit (1909 update), 16Gb RAM, JTDX 2.1.0-rc144 and logging to DXKeeper.

 

73 de BARRY MURRELL ZS2EZ

KF26ta - Port Elizabeth, South Africa

EPC#0558 DMC#1690  30MDG#4081

DXCC HONOR ROLL (332/340)

DXCC(mixed)#41,146  DXCC(RTTY)#1,916

DXCC(phone)#34,990  DXCC(CW)#11,714

DXCC 80m,40m,30m,20m,17m,15m,12m,10m   5BDXCC#8,916

WAS Triple Play #492  WAS(RTTY)#538  WAS(Digital)#163-Endorsements JT65,FT8

WAZ(RTTY)#185  WAE-I(mixed)#72  WAZS(mixed)#214  AAA#1569

AS ZR6DXB: VUCC(50MHZ)#1,334  UKSMG WAE(Silver)#75  UKSMG AFRICA#22  WAC (Satellite)

website : www.zs2ez.co.za

 

 


locked Sound Not Working in 2.15.4

Barry Murrell ZS2EZ
 

Hi Laurie

 

Installed the new 2.15.4 version – sound stopped working. Reverted back to 2.15.3 – works perfectly.

 

I use the onboard Realtek sound card for my alerts/system sounds etc – it is the Windows Default sound card, but is selected by name in JTAlert.

 

Before reverting back I tried restarting the PC, to no avail. Running Windows 10 64 Bit (1909 update), 16Gb RAM, JTDX 2.1.0-rc144 and logging to DXKeeper.

 

73 de BARRY MURRELL ZS2EZ

KF26ta - Port Elizabeth, South Africa

EPC#0558 DMC#1690  30MDG#4081

DXCC HONOR ROLL (332/340)

DXCC(mixed)#41,146  DXCC(RTTY)#1,916

DXCC(phone)#34,990  DXCC(CW)#11,714

DXCC 80m,40m,30m,20m,17m,15m,12m,10m   5BDXCC#8,916

WAS Triple Play #492  WAS(RTTY)#538  WAS(Digital)#163-Endorsements JT65,FT8

WAZ(RTTY)#185  WAE-I(mixed)#72  WAZS(mixed)#214  AAA#1569

AS ZR6DXB: VUCC(50MHZ)#1,334  UKSMG WAE(Silver)#75  UKSMG AFRICA#22  WAC (Satellite)

website : www.zs2ez.co.za

 

 


locked Re: UDP port problems

Rick Johnson
 

That is why I reinstalled JTAlert.....to reload the files and it didn't work of course.
I sent my files once before but I don't remember how.  The Parkinson's is getting worse.
I'll figure it out.  Thanks for the help.
73,
Rick W3BI


On Wed, Dec 4, 2019 at 6:25 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 5/12/2019 9:34 am, Rick Johnson wrote:
Thinking about the problem.....I used Revo Uninstall to remove an Acom program.  I think in the list of 
"leftovers" was an important file for JTAlert.  It wasn't listed as such or I would have removed it before 
deleting the other files. Any idea what I did wrong?  
To answer your question, JTAlert 2.14.5 and WSJT 2.1.2 worked perfectly.

Revo removing needed JTAlert files would not cause JTAlert to stop receiving UDP data from WSJT-X, if anything it would produce a critical error dialog from JTAlert which would subsequently close. A rerunning of the JTAlert installer will restore any lost files/directories.

There have not been any recent changes in how JTAlert receives WSJT-X UDP traffic, internally 2.15.3 is exactly the same as 2.14.5.

The most likely cause is another application having exclusive access to the WSJT-X UDP port (2237) or WSJT-X is running with elevated privileges (set to run as administrator). There is never any need to run WSJT-X elevated.

If you haven't done so already, perform a PC restart, especially if your running Win10 as that is now the most common fix for unexpected or changed behavior.

If you still have no success, use the "Help" (or "? ") -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA


locked New JTAlert 2.15.4 is available. #Announcement #NewRelease

HamApps Support (VK3AMA)
 
Edited

The Latest JTAlert version 2.15.4 is now available @ https://hamapps.com/JTAlert/

This release has a critical fix for "NO Log" users.

Please review the Release notes at the end of this message.

de Laurie VK3AMA

The Release Notes...
2.15.4 (04-DEC-2019)

  *** Includes Callsign database file version 2019-12-02 (2019-December-02)

  Changes:

    - The Windows Default Sound Device is NO longer supported as one of the
       selected audio devices. A specific named device must be set.
       JTAlert will now present a dialog to change the device whenever it
       encounters (at startup) the last used named device is no longer found
       or was never set (ie was using the Windows default).

    - JTAlert no longer uses fixed UDP ports for inter-process communications
       between JTAlert.exe and JTAlertV2.Manager.exe. Ports are now assigned
       by the Windows OS from free ports in the range 49152 to 65535.

  Fixes:

    - Mode not written to the B4Log.mdb file when logging is disabled.


de Laurie VK3AMA


locked Re: JTAlert Log issue

Robert T
 


Laurie,
The log functions have started woring again.   The only thing I know I did was close and reopen WSJT-X and JTAlert.   I guess the restart fixed the issue.

Tnx
Bob, K2RET

On December 4, 2019 at 5:08 PM "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...> wrote:

On 5/12/2019 4:01 am, Robert T wrote:
I am using JTAlert to log my QSO's to DXLabs DXKeeper.  This functions fine.
I also have JTAlert logging all Q's to my QRZ callbook and Clublog, and HRDlog automatically.  This function used to work.  Each time I entered a qso it would update my online logs.  Today I made about 20 FT-8 contacts and none have shown up in QRZ, Clublog or HRDLog.

Anyone have a clue as to what may have happened?

JTAlert version is 2.15.3
Callsign database ver. 2019.12.02
Sound files ver. 2.5.1
Online Logbooks:
QRZ.com is checked and API Key is correct
ClubLog is checked, and Call and password are correct
HRDLog is checked, Call and password are correct.

Now what?

TU,
Bob, K2RET
Bob,

All online log uploads are handled by the JTAlertV2.Manager process, while DXK logging is handled directly from the main JTAlert process.

Do other JTAlertV2.Manager handled functions work, like Audio, Text messages and Band Activity display, or are they similarly proken?

The last time the online log uploads worked was it with JTAlert 2.15.3 or an earlier version? If it was an earlier version what version, was it prior to 2.15.1?

Please let me know the answers to the above questions.

If the uploads worked previously with 2.15.3, then I suggest as a first diagnostic step perform a PC reboot. If that doesn't correct the behavior, wait a few hours for the next JTAlert release (2.15.4).

de Laurie VK3AMA


 


locked Re: Worked B4??

HamApps Support (VK3AMA)
 

On 5/12/2019 1:59 am, Neil Foster wrote:
Hi Mike and Laurie,
No, I had not done a "Scan Log and Rebuild" I will. And Laurie, Yes I see one or two as worked "B4". I use Ham Radio Deluxe...latest version, and have for many years.
Neil   N4FN
Neil,

A scan Log & rebuild will NOT resolve any B4 issues your having, it only affects the internal lists used by the Wanted Alerts.

If your seeing some B4s on the Band and not a total absence of B4s suggests the likely cause is within your Log file and JTAlert is not finding suitable entries when it does a B4 check.

Are the missing B4s for previously logged FT4 QSOs? If so you will likely find that HRDLogbook has them recorded as MFSK without a submode (the HRD Log schema doesn't have a SUBMODE column).

If an incorrect logged mode is not the answer, send me a copy of your HRD log file for analysis (only if it is an MSAccess type). Don't send the log via the group, send it to me direct.

Let me know what you find.

de Laurie VK3AMA


locked Re: UDP port problems

HamApps Support (VK3AMA)
 

On 5/12/2019 9:34 am, Rick Johnson wrote:
Thinking about the problem.....I used Revo Uninstall to remove an Acom program.  I think in the list of 
"leftovers" was an important file for JTAlert.  It wasn't listed as such or I would have removed it before 
deleting the other files. Any idea what I did wrong?  
To answer your question, JTAlert 2.14.5 and WSJT 2.1.2 worked perfectly.

Revo removing needed JTAlert files would not cause JTAlert to stop receiving UDP data from WSJT-X, if anything it would produce a critical error dialog from JTAlert which would subsequently close. A rerunning of the JTAlert installer will restore any lost files/directories.

There have not been any recent changes in how JTAlert receives WSJT-X UDP traffic, internally 2.15.3 is exactly the same as 2.14.5.

The most likely cause is another application having exclusive access to the WSJT-X UDP port (2237) or WSJT-X is running with elevated privileges (set to run as administrator). There is never any need to run WSJT-X elevated.

If you haven't done so already, perform a PC restart, especially if your running Win10 as that is now the most common fix for unexpected or changed behavior.

If you still have no success, use the "Help" (or "? ") -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA


locked Re: UDP port problems

Rick Johnson
 

Thinking about the problem.....I used Revo Uninstall to remove an Acom program.  I think in the list of 
"leftovers" was an important file for JTAlert.  It wasn't listed as such or I would have removed it before 
deleting the other files. Any idea what I did wrong?  
To answer your question, JTAlert 2.14.5 and WSJT 2.1.2 worked perfectly.

On Wed, Dec 4, 2019 at 5:11 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 5/12/2019 3:34 am, Rick Johnson wrote:

JTAlert 2.15.3 will not communicate with WSJT-X 2.1.2.  Get the famous

I have rebooted the computer, reloaded both programs, checked that the 3 boxes are checked.  I don’t know what else to do.

The setup in config for WSJT is correct.  I have not changed my virus software….same ones that have been running for months.

Can someone suggest something.

 

73, Rick W3BI

Rick,

Did JTAlert work previously and this is new behavior? If new, the likely cause is another application started prior to JTAlert taking exclusive control of the WSJT-X UDP server port (2237). Have you introduced any new apps that work directly with the WSJT-X UDP data?

de Laurie VK3AMA


locked Re: UDP port problems

HamApps Support (VK3AMA)
 

On 5/12/2019 3:34 am, Rick Johnson wrote:

JTAlert 2.15.3 will not communicate with WSJT-X 2.1.2.  Get the famous

I have rebooted the computer, reloaded both programs, checked that the 3 boxes are checked.  I don’t know what else to do.

The setup in config for WSJT is correct.  I have not changed my virus software….same ones that have been running for months.

Can someone suggest something.

 

73, Rick W3BI

Rick,

Did JTAlert work previously and this is new behavior? If new, the likely cause is another application started prior to JTAlert taking exclusive control of the WSJT-X UDP server port (2237). Have you introduced any new apps that work directly with the WSJT-X UDP data?

de Laurie VK3AMA


locked Re: JTAlert Log issue

HamApps Support (VK3AMA)
 

On 5/12/2019 4:01 am, Robert T wrote:
I am using JTAlert to log my QSO's to DXLabs DXKeeper.  This functions fine.
I also have JTAlert logging all Q's to my QRZ callbook and Clublog, and HRDlog automatically.  This function used to work.  Each time I entered a qso it would update my online logs.  Today I made about 20 FT-8 contacts and none have shown up in QRZ, Clublog or HRDLog.

Anyone have a clue as to what may have happened?

JTAlert version is 2.15.3
Callsign database ver. 2019.12.02
Sound files ver. 2.5.1
Online Logbooks:
QRZ.com is checked and API Key is correct
ClubLog is checked, and Call and password are correct
HRDLog is checked, Call and password are correct.

Now what?

TU,
Bob, K2RET
Bob,

All online log uploads are handled by the JTAlertV2.Manager process, while DXK logging is handled directly from the main JTAlert process.

Do other JTAlertV2.Manager handled functions work, like Audio, Text messages and Band Activity display, or are they similarly proken?

The last time the online log uploads worked was it with JTAlert 2.15.3 or an earlier version? If it was an earlier version what version, was it prior to 2.15.1?

Please let me know the answers to the above questions.

If the uploads worked previously with 2.15.3, then I suggest as a first diagnostic step perform a PC reboot. If that doesn't correct the behavior, wait a few hours for the next JTAlert release (2.15.4).

de Laurie VK3AMA


locked JTAlert Log issue

Robert T
 


GM All,

I am using JTAlert to log my QSO's to DXLabs DXKeeper.  This functions fine.
I also have JTAlert logging all Q's to my QRZ callbook and Clublog, and HRDlog automatically.  This function used to work.  Each time I entered a qso it would update my online logs.  Today I made about 20 FT-8 contacts and none have shown up in QRZ, Clublog or HRDLog.

Anyone have a clue as to what may have happened?

JTAlert version is 2.15.3
Callsign database ver. 2019.12.02
Sound files ver. 2.5.1
Online Logbooks:
QRZ.com is checked and API Key is correct
ClubLog is checked, and Call and password are correct
HRDLog is checked, Call and password are correct.

Now what?

TU,
Bob, K2RET


locked Re: JT-Alert Will Not Run

Paul
 

Laurie,

 

Thank you.  The callsign entry was indeed missing in the registry.  I added it per your suggestion and JT-Alert now runs.  Thanks again.  Much appreciated.

 

73…  Paul (VE3PS)

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Paul
Sent: December 3, 2019 23:40
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JT-Alert Will Not Run

 

Thanks very much Laurie.  I will definitely look into this tomorrow morning.

 

73…  Paul (VE3PS)

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: December 3, 2019 23:33
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JT-Alert Will Not Run

 

On 4/12/2019 2:56 pm, Paul wrote:

When WSJT-X is running, I then attempt to launch JT-Alert.  A small window pops up [Reading Settings Data/Standby] and after perhaps 40 seconds a second small window pops up with an error message [Missing or Invalid Callsign/Program will now exit].  The only option is to click OK, and the program does indeed close.

Any assistance would be greatly appreciated.

Thanks/73...  Paul (VE3PS)

Paul,

JTAlert will abort trying to start if it is unable to determine your Callsign as that controls which config file to load.
Either the necessary Registry entry is missing or your PC protection software is actively blocking JTAlert from reading the Registry key (which JTAlert creates and owns).

You can check the Registry by using Regedit and navigating to the "HKEY_CURRENT_USER\Software\HamApps" key and looking for the "callsign" entry.
eg.
  

If the callsign entry is present then you need to look to your PC Protection software as it is likely the culprit with some overzealous settings. Any File/Folder exceptions you have added will not prevent Registry read blocking, that will be (usually) hidden deep within the Protection software settings.

If the callsign registry entry is missing, you can add it (new string value).

Alternatively you can create a new JTAlert shortcut specifying the callsign. This is the method I use to test multiple different callsigns.
Simply copy the JTAlert shortcut you normally use, right-click that new shortcut, select "Properties" and edit the "Target" field of the "Shortcut" tab adding the following /callsign=VE3PS after the /wsjtx or /jtdx parameter.
eg.
   

de Laurie VK3AMA


locked UDP port problems

Rick Johnson
 

JTAlert 2.15.3 will not communicate with WSJT-X 2.1.2.  Get the famous

 

 

I have rebooted the computer, reloaded both programs, checked that the 3 boxes are checked.  I don’t know what else to do.

The setup in config for WSJT is correct.  I have not changed my virus software….same ones that have been running for months.

Can someone suggest something.

 

73, Rick W3BI

polarmail@...

 

 

 

Sent from Mail for Windows 10

 


locked Re: Worked B4??

Neil Foster
 

Hi Mike and Laurie,
No, I had not done a "Scan Log and Rebuild" I will. And Laurie, Yes I see one or two as worked "B4". I use Ham Radio Deluxe...latest version, and have for many years.
Neil   N4FN


locked Re: Suggestion for next release

Dwaine Pipe
 

Hi Laurie

 

I fully appreciate your comments on existing users and thank you for changing the auto-close for new users 😊

 

Cheers

David

VK7YUM

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Wednesday, 4 December 2019 10:11 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Suggestion for next release

 

On 3/12/2019 7:20 pm, Dwaine Pipe wrote:

For the next release, would it be possible to change the default time out for the TXT MSG window from whatever it currently is (wayyy too short) to the setting of "Stay on screen until closed"   which I think is an unticked "Auto Close" box......

I suggest this because there are lots and lots of users that I send messages to that actually have no idea that the message box even exists and they just don't get enough time to read what pops up before it vanishes.    I frequently get emails saying "how the hell did you do that"  meaning the message I sent.

Thanks for considering.
Cheers
David
VK7YUM


The default timeout is 20 seconds. I wouldn't characterize that as too short.

While I can alter the default setting to "No Auto Close" that will only affect new users with newly created config files. The default value only gets assigned when reading the setting during startup and the settings is not found (as with a new empty config file). The default is only applied once which creates the missing setting and will never be performed automatically again.

Changing any existing setting for current users is not something I do unless it is an unavoidable change due to code/functionality changes (ie is deemed mandatory).

Altering the auto-close property of the text message window for all exiting users is not an option IMO. I will however set the "No Auto Close" as the new default starting with the next JTAlert release.

de Laurie VK3AMA


locked Re: Rescanning log for prefixes

HamApps Support (VK3AMA)
 

On 4/12/2019 12:48 am, stuartliss@... wrote:
When JTAlert scans for wanted prefixes, it finds no prefixes.  Previously, it found 400 fewer than the number of prefixes, so it reported many false positives.

I also scanned for states and it found none.  I set the states for each band manually.

How do I get it to find all of the prefixes?

Thanks,

Stuart K2YYY
Stuart,

What logger do you have enabled?

If the Scan is not finding prefixes then your log doesn't contain the Prefix data recorded with each QSO.
Similarly for States, if a QSO doesn't specify a State, the QSO is ignored during the scanning.

JTAlert does not make any attempt to determine missing data during the Scan.

If data is missing from your Log then you should investigate why and correct the QSOs.

de Laurie VK3AMA


locked Re: JT-Alert Will Not Run

Paul
 

Thanks very much Laurie.  I will definitely look into this tomorrow morning.

 

73…  Paul (VE3PS)

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: December 3, 2019 23:33
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JT-Alert Will Not Run

 

On 4/12/2019 2:56 pm, Paul wrote:

When WSJT-X is running, I then attempt to launch JT-Alert.  A small window pops up [Reading Settings Data/Standby] and after perhaps 40 seconds a second small window pops up with an error message [Missing or Invalid Callsign/Program will now exit].  The only option is to click OK, and the program does indeed close.

Any assistance would be greatly appreciated.

Thanks/73...  Paul (VE3PS)

Paul,

JTAlert will abort trying to start if it is unable to determine your Callsign as that controls which config file to load.
Either the necessary Registry entry is missing or your PC protection software is actively blocking JTAlert from reading the Registry key (which JTAlert creates and owns).

You can check the Registry by using Regedit and navigating to the "HKEY_CURRENT_USER\Software\HamApps" key and looking for the "callsign" entry.
eg.
  

If the callsign entry is present then you need to look to your PC Protection software as it is likely the culprit with some overzealous settings. Any File/Folder exceptions you have added will not prevent Registry read blocking, that will be (usually) hidden deep within the Protection software settings.

If the callsign registry entry is missing, you can add it (new string value).

Alternatively you can create a new JTAlert shortcut specifying the callsign. This is the method I use to test multiple different callsigns.
Simply copy the JTAlert shortcut you normally use, right-click that new shortcut, select "Properties" and edit the "Target" field of the "Shortcut" tab adding the following /callsign=VE3PS after the /wsjtx or /jtdx parameter.
eg.
   

de Laurie VK3AMA


locked Re: JT-Alert Will Not Run

HamApps Support (VK3AMA)
 

On 4/12/2019 2:56 pm, Paul wrote:
When WSJT-X is running, I then attempt to launch JT-Alert.  A small window pops up [Reading Settings Data/Standby] and after perhaps 40 seconds a second small window pops up with an error message [Missing or Invalid Callsign/Program will now exit].  The only option is to click OK, and the program does indeed close.

Any assistance would be greatly appreciated.

Thanks/73...  Paul (VE3PS)
Paul,

JTAlert will abort trying to start if it is unable to determine your Callsign as that controls which config file to load.
Either the necessary Registry entry is missing or your PC protection software is actively blocking JTAlert from reading the Registry key (which JTAlert creates and owns).

You can check the Registry by using Regedit and navigating to the "HKEY_CURRENT_USER\Software\HamApps" key and looking for the "callsign" entry.
eg.
  

If the callsign entry is present then you need to look to your PC Protection software as it is likely the culprit with some overzealous settings. Any File/Folder exceptions you have added will not prevent Registry read blocking, that will be (usually) hidden deep within the Protection software settings.

If the callsign registry entry is missing, you can add it (new string value).

Alternatively you can create a new JTAlert shortcut specifying the callsign. This is the method I use to test multiple different callsigns.
Simply copy the JTAlert shortcut you normally use, right-click that new shortcut, select "Properties" and edit the "Target" field of the "Shortcut" tab adding the following /callsign=
VE3PS after the /wsjtx or /jtdx parameter.
eg.
   

de Laurie VK3AMA

7861 - 7880 of 34374