Date   

locked Re: JTAlert 2.15.11 ERROR/BUG #Important

WA2NDV <frankatcvc@...>
 
Edited

I also have this error.
Turned off sound and it has not happened again.

What is the default directory for install? Some time ago I changed it and I keep putting updates in its own folder. I did not do that for this update.

Maybe this has something to do with the issue?



73
Frank
WA2NDV


locked Re: Wanted US State Not Updating

HamApps Support (VK3AMA)
 

On 26/02/2020 9:44 am, JP wrote:
For about 80% of my QSOs, once I work a new state (or DXCC entity) I no longer see that state (or DXCC entity) as wanted, which is at it should be.

However, for the remaining 20%, the wanted/unwanted status does not change.

The 80% represents Stations already worked and logged so they become B4's and will not generate alerts. The 20% would be new un-worked stations generating the Alert because that Alert entity is still marked as needed.

See my reply to your original message where I go into more detail https://hamapps.groups.io/g/Support/message/28000



locked Re: Wanted US State Not Updating

HamApps Support (VK3AMA)
 

On 25/02/2020 3:42 am, JP wrote:
Running into this problem repeatedly
Worked a station FT8 that was a new state on the band.  After I logged it (log alert looks okay), other stations in same state still show up as needed ON THE SAME BAND with the same mode.  For example, worked W1WWB (North Carolina, grid EM95) on 40 meters - first time for that state and grid on that band.  Hours later, I'm still getting North Carolina stations as alerts as "Wanted US State". 

I have following settings 
Wanted US State - by Individual Band, by Individual Mode - Mode FT8
Wanted Grid - by Individual Band, by Individual Mode - Mode FT8
Filters - Do not show Worked Before (B4) Callsigns
Using Standard ADIF File Logging

The W1WWB contact is logged in both WSJT-X log and in JTAlert log.

Jon, AI1V
Jon,

This is expected behavior.

JTAlert does not automatically remove a Wanted Alert entity by simply working and logging a QSO. It requires that the entity is physically removed under the Settings, either manually or by the preferred "Scan Log and Rebuild" method.

For the majority of users, they require some sort of QSL confirmation for an Alert entity to be considered no longer needed. JTAlert has been designed around getting those log confirmations during the Scan, automating the process. The Scan Log does have QSL options so that a worked station without any QSL confirmation is sufficient for an entity to be no longer considered. From your description, it is this worked only option you need to use when running a Scan Log.

JTAlert will not alert if a station that would generate a needed Alert if they have been previously worked (is a B4) which prevents decodes of a newly logged station from continuing to generate an alert. New stations, previously un-worked will generate the alert until the Alert entity is removed from the internal wanted lists.

The ability to automatically (without manual or Scan Log updating) set an Alert entity as no longer needed after working a station is on the todo list, but implementation is not imminent.

de Laurie VK3AMA




locked Re: JTAlert 2.15.11 ERROR/BUG #Important

HamApps Support (VK3AMA)
 

On 26/02/2020 10:01 am, Franco HB9oab wrote:
This error in JTalert 2.15.11 appears during normal use:

TAGS: #BUG #ERROR   ;-)



73's
Franco

Franco,

That error line number is within the Sound play code.

Please disable sounds
so that the menu shows "Sound OFF" code. Do you still get this error?

I can't reproduce the problem in testing and there have been no other reports. The Test team had this build for 2 days prior to release and there were no reports of this error.

I suspect something specific to your installation.
Please do the following...
  • Uninstall of JTAlert (using Windows Control Panel, Programs and Features entry).
  • Delete any remaining files and folders in your old JTAlert Install directory.
  • Reinstall JTAlert.
  • If you still get this error, 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: JTAlert 2.15.11 ERROR/BUG #Important

Franco
 

HI All

I have checked many times and this happens when there is a US call with the State



73's
Franco


locked Re: False QSO Not Logged message with ACLog6.6

Charlie Hoffman
 

Please tell me how you changed the priorities from normal to high on JTAlert, WSJT-X, and ACLog?


locked JTAlert 2.15.11 ERROR/BUG #Important

Franco
 
Edited

This error in JTalert 2.15.11 appears during normal use:

TAGS: #BUG #ERROR   ;-)



Never happened with previous versions... 

73's
Franco


locked Re: Wanted US State Not Updating

WB8ASI Herb
 

Each Alert can be set up by Individual Band or Any Band.  Maybe take a double check on that to be sure you're getting what you want.  Otherwise don't know why 20% are unexpected.  73, Herb

On February 25, 2020 at 5:44 PM JP <jon.perelstein@...> wrote:

Thanks for your reply Herb.  I have them all unchecked.  For about 80% of my QSOs, once I work a new state (or DXCC entity) I no longer see that state (or DXCC entity) as wanted, which is at it should be.

However, for the remaining 20%, the wanted/unwanted status does not change.

73
Jon, AI1V

 


locked Re: Wanted US State Not Updating

JP
 

Thanks for your reply Herb.  I have them all unchecked.  For about 80% of my QSOs, once I work a new state (or DXCC entity) I no longer see that state (or DXCC entity) as wanted, which is at it should be.

However, for the remaining 20%, the wanted/unwanted status does not change.

73
Jon, AI1V


locked Re: LoTW Flag not always correct

Paul AC9O
 

I did just see a case where the LoTW flag is not displayed, but it is in WSJT-X and in ACLog. The last upload date is 2020-02-16 so it's within a year. The call is ZW86LABRE. Is it possibly just a very new call that isn't in your database?


locked Re: Auto-start question

HamApps Support (VK3AMA)
 

On 26/02/2020 8:21 am, Carter wrote:
1) DX Lab Commander
2) DXKeeper
3) WSJT-X
4) JT Alert
I would put DXKeeper last.
DXKeeper can be very slow to startup. It is not critical to be running until you want to log a QSO so starting last will not present a problem.

de Laurie VK3AMA


locked Re: Auto-start question

Dave Garber
 

when I tried the autostart with my log, etc.  I always started the cat program first, the jtalert, which would call up wsjt and my log program

never an issue that way.   perhaps you start times should be spaced further, if needed.   commander needs no delay, then dxkeeper at 100 ( try, maybe need higher), then wsjt after additional time period
Dave Garber
VE3WEJ / VE3IE


On Tue, Feb 25, 2020 at 4:21 PM Carter <k8vt@...> wrote:
I used JT Alert about 3 years ago with JT65/JT9 but still consider myself a newbie, just having got back on the air with FT-8.
I manually start from desktop icons (in the order listed):
1) DX Lab Commander
2) DXKeeper
3) WSJT-X
4) JT Alert

Everything works fine - radio control, making split contacts, logging to DXKeepeer and LoTW, etc. However, it was a bit tiresome starting all those programs individually, so Auto-start seemed like a great idea!

In JT Alert: Settings>Applications>Auto-Start.

I had #1 as Commander, 1000ms
#2 as DXkeeper, 1000ms
#3 WSJT-X, which changed by itself to 1500 ms.

Then I click on the desktop icon for JT Alert. This gives a variety of errors (sorry, did not write them all down), WSJT-X no longer recognizing the radio, etc.

Any thoughts on what order I should have the auto-start programs in? Any suggestions on what I am doing wrong?

Thanks in advance and 73,
Carter  K8VT


locked Re: Auto-start question

Michael Black
 

Try starting WSTJ-X a bit later to let DX programs get going first.

de Mike W9MDB




On Tuesday, February 25, 2020, 03:21:59 PM CST, Carter <k8vt@...> wrote:


I used JT Alert about 3 years ago with JT65/JT9 but still consider myself a newbie, just having got back on the air with FT-8.
I manually start from desktop icons (in the order listed):
1) DX Lab Commander
2) DXKeeper
3) WSJT-X
4) JT Alert

Everything works fine - radio control, making split contacts, logging to DXKeepeer and LoTW, etc. However, it was a bit tiresome starting all those programs individually, so Auto-start seemed like a great idea!

In JT Alert: Settings>Applications>Auto-Start.

I had #1 as Commander, 1000ms
#2 as DXkeeper, 1000ms
#3 WSJT-X, which changed by itself to 1500 ms.

Then I click on the desktop icon for JT Alert. This gives a variety of errors (sorry, did not write them all down), WSJT-X no longer recognizing the radio, etc.

Any thoughts on what order I should have the auto-start programs in? Any suggestions on what I am doing wrong?

Thanks in advance and 73,
Carter  K8VT


locked Auto-start question

Carter
 

I used JT Alert about 3 years ago with JT65/JT9 but still consider myself a newbie, just having got back on the air with FT-8.
I manually start from desktop icons (in the order listed):
1) DX Lab Commander
2) DXKeeper
3) WSJT-X
4) JT Alert

Everything works fine - radio control, making split contacts, logging to DXKeepeer and LoTW, etc. However, it was a bit tiresome starting all those programs individually, so Auto-start seemed like a great idea!

In JT Alert: Settings>Applications>Auto-Start.

I had #1 as Commander, 1000ms
#2 as DXkeeper, 1000ms
#3 WSJT-X, which changed by itself to 1500 ms.

Then I click on the desktop icon for JT Alert. This gives a variety of errors (sorry, did not write them all down), WSJT-X no longer recognizing the radio, etc.

Any thoughts on what order I should have the auto-start programs in? Any suggestions on what I am doing wrong?

Thanks in advance and 73,
Carter  K8VT


locked JTAlert 2.15.11 is available. #Announcement #NewRelease

HamApps Support (VK3AMA)
 

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

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

de Laurie VK3AMA

Release Notes.

2.15.11 (24-FEB-2020)

  New Features:

    - Audio Play Limit Period: Individual audio alerts will play once per time
       period (max 5 minutes). Set via the "Sound" menu or the Settings window.
       Limit does not apply to "Own Call" and "Out of shack" alerts.
       (Default: No limit, Window: Settings, Section: SoundCard).

  Changes:

    - Callsign Database: Significant reduction in size due to removal of non
       active Callsigns (not spotted in last 6 months). Size is now ~2.5MB,
       previously ~33MB.

    - Callsigns Display: Improved display speed with less redraw flashing.

  Fixes:

    - ADIF Logging: SQLite error when logging "Cote d'Ivoire" country name QSOs.

    - Log4OM2 MySQL: Scan Log failing to find QSL confirmed QSOs.

    - Log4OM2 MySQL: Scan Log failing (returning all entities as need) for non-Windows
       hosted MySQL servers (Linux or MAC). Windows hosted MySQL was not affected.
       (Thanks! to Jorgen, NU1T, for uncovering the source of this defect)



locked Re: Wanted US State Not Updating

WB8ASI Herb
 

Jon,   See attached.  I have LOTW selected as my confirmation, so I still see anything as being "Wanted" until I receive the LOTW.   I imagine if you have them all unchecked, you might see it removed from your "Wanted" list upon working them, but I've never tried that.  73, Herb WB8ASI
On February 25, 2020 at 9:07 AM JP <jon.perelstein@...> wrote:

Herb

Thank you for your reply.  I can't find "required for confirmation" as a setting or filter.  Where is it located?

73
Jon, AI1V

 


locked Re: JTAlert is closing (crashing) after logging or settings change

Rich McCabe
 

Mike

Done.


locked Re: Wanted US State Not Updating

JP
 

Herb

Thank you for your reply.  I can't find "required for confirmation" as a setting or filter.  Where is it located?

73
Jon, AI1V


locked Re: JTAlert is closing (crashing) after logging or settings change

Michael Black
 

You'll need to send in a bug report via Help/Contact Support

de Mike W9MDB



On Tuesday, February 25, 2020, 07:45:44 AM CST, Rich McCabe <r.mccabe@...> wrote:


I have an issue all of a sudden where JTalert will close after logging (Log4OM V2).  I thought maybe it had something to do with log4OM so I disabled that but still happens. I can go into the settings menu and click OK to leave and it does it as well.

The calls that it crashed on are not showing as worked either.  They did make it to log4OM when I had it enabled.

Rich


locked Re: JTAlert is closing (crashing) after logging or settings change

Rich McCabe
 

And I am getting an AutoIT Error on occasion now for JTAlert_AL.exe  for variable used without being declared.