Date   

locked Re: Logging failures do not update worked before information

g4wjs
 

On 10/05/2020 23:22, HamApps Support (VK3AMA) wrote:
On 10/05/2020 6:22 am, g4wjs wrote:
Hi Laurie,

it seems that when JTAlert cannot confirm logging of a QSO in the configured logging application it does not update its internal worked before database. Often these logging failures are due to slow updates to the logging application even though the log is eventually updated. Restarting JTAlert does sort it out but until then it is easy to mistakenly work the same station twice.



-- 
73
Bill
G4WJS.
Hi Bill,

Your correct, the internal B4 cache (held in memory) does not get updated if JTAlert is unable to confirm a QSO was logged.

What Logger are you using that is experiencing the delays?

If your logger is consistently slow in writing the QSO to the log file/database and your happy that QSOs are reliably getting logged, there is the option is to turn on the "Do not check or report logging success/failure" serring, under the Logging section of the Settings (scroll the checkbox display down). With that set, JTAlert will set the B4 status regardless and not perform any code-blocking checks.

There is the option to increase the QSO check time, but that can be problematic, especially with the short period FT4, as the delay QSO check delay, which is blocking the UI thread, can extend into the new decode period and JTAlert may miss the period. The main JTAlert code is single-threaded and synchronous (no async functionality) so any additional delay added to the QSO logged check function blocks there entire code.

Rather than restarting JTAlert you can use the "Alerts -> Clear B4 cache" menu (2nd from the top).

de Laurie VK3AMA

Hi Laurie,

I am using DXKeeper for logging. My delay before checking is set to 8 seconds which is perfectly adequate 99% or more of the time, but occasionally when my machine is particularly busy it trips up. Thanks for the tip on clearing the B4 cache. How about my suggestion of a "Retry" button alongside the "Ok" button on the error message about not confirming the logging success, in my case that would cover all the cases as far as I know, assuming a successful retry that finds the logged QSO goes on to update the worked B4 cache in JTAlert.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


locked Re: I miss the old layout

Uwe, DG2YCB
 

Hi Laurie,

Thank you for your answer. Yes, I understand your point of view. However, allow me to suggest another solution that could meet both aspects:

At the "B" versions of my wsjt-x clones I placed a small switchable object in the top left corner to toggle Controls on/off without interfering the scale of teh Wide Graph window. Works well. Couldn't that be a solution for JTAlert too?

I don't know what it's for, but sometimes I see at the JTAlert window a small triangle/arrow. Couldn't that be used to toogle menu on/off? See screenshot below including an idea how it could look like when menus are disabled: 



73 de Uwe, DG2YCB


locked Re: JTAlert 2.16.5 Download

chas cartmel
 

Not had an issue with this version or any others with any of the AV software I have used in the past.

 

 

Charlie

G4EST

www.g4est.me.uk

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Jim N6VH
Sent: 10 May 2020 23:05
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert 2.16.5 Download

 

On 5/10/2020 10:15 AM, Robert T wrote:

 

Has anyone been able to download and successfully install ver 2.16.5 without their virus scan deleting the install saying it has a virus?

 

Bob, K2RET


This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com


locked New Marathon visual alert fault \ It's about priority

asobel@...
 

The problem was solved by increasing the priority of marathon. It is
apparent that verbal alerts enjoy different priority then visual alerts.

Amos 4X4MF

============
I am using the CQ Marathon alert on JTAlert 2.16.5 and earlier. The CQ
Marathon is producing a lot of verbal alerts but most of the time the visual
alert on both the WSJT-X and JTAlert displays are missing which makes the
alert quite useless.

For your information, I am using 4 instances of WSJT-X and JTAlert.

Please fix it ASAP.

Amos Sobel 4X4MF


locked Re: The call database shows that I operate from MN, I have never had an address there #FT8

John
 

QRZ.com has you in OR, that is where the info came from probably, change it at
QRZ.com.

John
VE3KKQ

---------- Original Message ----------
From: aa7g.gert@gmail.com
Date: May 10, 2020 at 11:16 PM


The JTAlert Call database shows that I operate from MN but the thing is I have
never had an address in that state. I don´t know why I have been associated
with that state in the call database. There are no official sources that lists
me in MN whatsoever and there never have been. Someone must have added AA7G in
MN to the call database so can that someone please correct my call to show ME
instead since I do all my FT8 operating from Maine. Thank you in advance,

Gert, AA7G with FCC address in Oregon but operating from Maine



locked The call database shows that I operate from MN, I have never had an address there #FT8

aa7g.gert@...
 

The JTAlert Call database shows that I operate from MN but the thing is I have never had an address in that state. I don´t know why I have been associated with that state in the call database. There are no official sources that lists me in MN whatsoever and there never have been. Someone must have added AA7G in MN to the call database so can that someone please correct my call to show ME instead since I do all my FT8 operating from Maine. Thank you in advance,

Gert, AA7G with FCC address in Oregon but operating from Maine


locked Re: JTAlert 2.16.5 Download

Kent Olsen
 

I did have a problem "downloading" it. I am using Windows Defender. I went into Windows settings under Update and Security. Windows Security, Virus & Threat Protection then Protection History where it showed "Threat blocked". I was able to restore the downloaded file from there.

Thanks
73
Kent
N6WT


On Sun, May 10, 2020 at 7:46 PM neil_zampella <neilz@...> wrote:

Yep .. I've never had a problem with AVG Internet Security.

Neil, KN3ILZ

On Sun, May 10, 2020 at 01:15 PM, Robert T wrote:

Has anyone been able to download and successfully install ver 2.16.5 without their virus scan deleting the install saying it has a virus?
 
Bob, K2RET


locked Re: JTAlert 2.16.5 Download

neil_zampella
 

Yep .. I've never had a problem with AVG Internet Security.

Neil, KN3ILZ


On Sun, May 10, 2020 at 01:15 PM, Robert T wrote:

Has anyone been able to download and successfully install ver 2.16.5 without their virus scan deleting the install saying it has a virus?
 
Bob, K2RET


locked Re: JTAlert 2.16.5 not highlighting Wanted Callsigns consistently?

Jim Reisert AD1C
 

Thanks Laurie. I did not know about the priorities. I assumed a
Wanted Callsign would always be the highest priority. I don't know
why anyone would not want it this way. Presumably, you added it
because you NEED to see that call highlighted for some reason.

73 - Jim

On Sun, May 10, 2020 at 4:23 PM HamApps Support (VK3AMA) via groups.io
<vk3ama.ham.apps=gmail.com@groups.io> wrote:

On 11/05/2020 3:10 am, Jim Reisert AD1C wrote:

Laurie, thanks for updating JTAlert in anticipation of the new RC of WSJT-X.

It seems that 2.16.5 may not be highlighting Wanted Callsigns
consistently. Example: KM4MQC is calling CQ on 10 meter FT8. I
right-clicked and added the call to my Wanted Callsigns list. The
next time he called CQ, JTAlert still showed a light-blue background
instead of a purple background.

Earlier to test this, I reverted to 2.16.4, and I did the same thing
for K1DG when he was calling CQ on 17m. His Wanted Callsign
highlighted as expected.

Has anyone else noticed this?

--
Jim Reisert AD1C


Jim,

This is not a defect, but expected behavior when a Wanted Callsign is generating other Alerts.

A Wanted Callsign alert is, by default, lower in priority than all the other Wanted Alerts.
Any higher priority triggered Alerts will influence how the Callsign is colored overriding any potential Wanted Call coloring.

If you had added a Callsign that was not generating any Alerts as a Wanted Callsign then when next decoded the Callsign would have been colored with the Wanted Alert colors.

You can adjust the Alert priorities under the "Alerts->Alerts Priority" section of the Settings window.

de Laurie VK3AMA



--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us


locked Re: Zones Problem

WB8ASI Herb
 

...and Log4OM also has the correct zones in its Main UI window, however something goes wrong upon the logging of the QSO.  It happens over and over again.  Guess we need more chatter on the Log4OM forum to get some attention.  Jim, I switched to HamQTH per your suggestion.  73 Herb WB8ASI

On May 10, 2020 at 9:07 PM Jim N6VH <N6VH@...> wrote:

Dave,

That isn't true. Log4OM does receive the correct zones from JTAlert, unless JTAlert doesn't have a zone to send (very rare). The problem is what Log4OM does with the info. As I already said in an earlier post, if Log4OM is set to do lookups, it will overwrite the info that is sent to it from JTAlert. If it doesn't get the ifo from QRZ (or wherever) it puts in either a "0" or a zone number that might not be correct. In the case of a station in the US, that will be "5" for the CQ zone. As I said in an earlier post, I tested this both with and without using lookups in Log4OM. If I didn't have Log4OM do lookups, it used the zones sent to it from JTAlert. If I had Log4OM do lookups from QRZ, using a call that QRZ didn't have zones for, then it used arbitrary zone numbers rather than the zones from JTAlert. So, yes, Log4OM does get the zones from JTAlert. The problem is what it does with them.

73,

Jim N6VH

On 5/10/2020 4:03 PM, Dave Garber wrote:
That's what I was trying to say.  Log4om is not receiving any correct info on itu and cq zones from j talert.  

sent by my LG phone

On Sun, May 10, 2020, 6:21 PM HamApps Support (VK3AMA), < vk3ama.ham.apps@...> wrote:
On 10/05/2020 12:58 pm, Dave Garber wrote:
> I suspect an issue with adi from jtalert

It is not a JTAlert problem. If JTAlert shows zones in the log fields
area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet
sent. JTAlert deliberately does not send any Zone numbers if the value
is NOT greater than zero. Similarly any data fields that are empty the
corresponding adif field is simply not included in the adif packet. That
is JTAlert only includes adif fields for non-empty and non-zero (> 1)
data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA





 


locked Re: Zones Problem

Jim N6VH
 

Dave,

That isn't true. Log4OM does receive the correct zones from JTAlert, unless JTAlert doesn't have a zone to send (very rare). The problem is what Log4OM does with the info. As I already said in an earlier post, if Log4OM is set to do lookups, it will overwrite the info that is sent to it from JTAlert. If it doesn't get the ifo from QRZ (or wherever) it puts in either a "0" or a zone number that might not be correct. In the case of a station in the US, that will be "5" for the CQ zone. As I said in an earlier post, I tested this both with and without using lookups in Log4OM. If I didn't have Log4OM do lookups, it used the zones sent to it from JTAlert. If I had Log4OM do lookups from QRZ, using a call that QRZ didn't have zones for, then it used arbitrary zone numbers rather than the zones from JTAlert. So, yes, Log4OM does get the zones from JTAlert. The problem is what it does with them.

73,

Jim N6VH

On 5/10/2020 4:03 PM, Dave Garber wrote:
That's what I was trying to say.  Log4om is not receiving any correct info on itu and cq zones from j talert.  

sent by my LG phone

On Sun, May 10, 2020, 6:21 PM HamApps Support (VK3AMA), <vk3ama.ham.apps@...> wrote:
On 10/05/2020 12:58 pm, Dave Garber wrote:
> I suspect an issue with adi from jtalert

It is not a JTAlert problem. If JTAlert shows zones in the log fields
area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet
sent. JTAlert deliberately does not send any Zone numbers if the value
is NOT greater than zero. Similarly any data fields that are empty the
corresponding adif field is simply not included in the adif packet. That
is JTAlert only includes adif fields for non-empty and non-zero (> 1)
data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA





locked Re: Zones Problem

Dave Garber
 

That's what I was trying to say.  Log4om is not receiving any correct info on itu and cq zones from j talert.  

sent by my LG phone

On Sun, May 10, 2020, 6:21 PM HamApps Support (VK3AMA), <vk3ama.ham.apps@...> wrote:
On 10/05/2020 12:58 pm, Dave Garber wrote:
> I suspect an issue with adi from jtalert

It is not a JTAlert problem. If JTAlert shows zones in the log fields
area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet
sent. JTAlert deliberately does not send any Zone numbers if the value
is NOT greater than zero. Similarly any data fields that are empty the
corresponding adif field is simply not included in the adif packet. That
is JTAlert only includes adif fields for non-empty and non-zero (> 1)
data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA





locked Re: JTAlert 2.16.5 not highlighting Wanted Callsigns consistently?

HamApps Support (VK3AMA)
 

On 11/05/2020 3:10 am, Jim Reisert AD1C wrote:
Laurie, thanks for updating JTAlert in anticipation of the new RC of WSJT-X.

It seems that 2.16.5 may not be highlighting Wanted Callsigns
consistently.  Example:  KM4MQC is calling CQ on 10 meter FT8.  I
right-clicked and added the call to my Wanted Callsigns list.  The
next time he called CQ, JTAlert still showed a light-blue background
instead of a purple background.

Earlier to test this, I reverted to 2.16.4, and I did the same thing
for K1DG when he was calling CQ on 17m.  His Wanted Callsign
highlighted as expected.

Has anyone else noticed this?

-- Jim Reisert AD1C

Jim,

This is not a defect, but expected behavior when a Wanted Callsign is generating other Alerts.

A Wanted Callsign alert is, by default, lower in priority than all the other Wanted Alerts.
Any higher priority triggered Alerts will influence how the Callsign is colored overriding any potential Wanted Call coloring.

If you had added a Callsign that was not generating any Alerts as a Wanted Callsign then when next decoded the Callsign would have been colored with the Wanted Alert colors.

You can adjust the Alert priorities under the "Alerts->Alerts Priority" section of the Settings window.

de Laurie VK3AMA


locked Re: Logging failures do not update worked before information

HamApps Support (VK3AMA)
 

On 10/05/2020 6:22 am, g4wjs wrote:
Hi Laurie,

it seems that when JTAlert cannot confirm logging of a QSO in the configured logging application it does not update its internal worked before database. Often these logging failures are due to slow updates to the logging application even though the log is eventually updated. Restarting JTAlert does sort it out but until then it is easy to mistakenly work the same station twice.



-- 
73
Bill
G4WJS.
Hi Bill,

Your correct, the internal B4 cache (held in memory) does not get updated if JTAlert is unable to confirm a QSO was logged.

What Logger are you using that is experiencing the delays?

If your logger is consistently slow in writing the QSO to the log file/database and your happy that QSOs are reliably getting logged, there is the option is to turn on the "Do not check or report logging success/failure" serring, under the Logging section of the Settings (scroll the checkbox display down). With that set, JTAlert will set the B4 status regardless and not perform any code-blocking checks.

There is the option to increase the QSO check time, but that can be problematic, especially with the short period FT4, as the delay QSO check delay, which is blocking the UI thread, can extend into the new decode period and JTAlert may miss the period. The main JTAlert code is single-threaded and synchronous (no async functionality) so any additional delay added to the QSO logged check function blocks there entire code.

Rather than restarting JTAlert you can use the "Alerts -> Clear B4 cache" menu (2nd from the top).

de Laurie VK3AMA


locked Re: Multiple instance JTAlert configuration.

HamApps Support (VK3AMA)
 

On 10/05/2020 5:19 am, asobel@... wrote:

Multiple  JTAlert instances are using common configuration. Sometimes I need to have it with separate configurations but I could not find a way to do it.

Is there a way of doing it?

Is this is not possible with the current software version, please consider adding it soon.

 

Amos 4X4MF

Sorry, separate configurations per JTAlert instance is not possible with the V2 series of JTAlert, it would require a significant code rewrite which will not happen. The V2 code is near EOL (End Of Life) and there will not be any further significant code changes, defect fixes and minor enhancements only. My focus is on getting JTAlertV3 finished any released, but that is still several months away unfortunately.

de Laurie VK3AMA


locked Re: I miss the old layout

HamApps Support (VK3AMA)
 

On 11/05/2020 12:33 am, Uwe wrote:
What if JTAlert makes it as Firefox has it? Right-hand click on the window title bar gives an option to show / hide the menus.

Or, alternatively, show the menu only when the mouse pointer hovers over the window title bar?

Could that be a way?
No, that wont be possible. It was the menus in the titlebar and the mouse position/click detection management that were the problem. The code for placing the menus (and the Band Activity display) in the titlebar was very complex due to limitations with the AutoIT compiler.

I have decided to abandon any further attempts at trying to correct the missing/misplaced menus defect experienced by some users (I was never able to reproduce the defect in testing). Maintaining two code bases was time consuming and error-prone.

Then there was the non-code issue with the seemingly endless support requests (on average 3 or 4 requests per week) from affected users who were either unwilling or unable to read the prominent display on the JTAlert download page advising of the use of the "Alt Layout" version to correct the missing menus problem.

If you wish to continue to have the Traditional Layout experience, your only option is to stay with 2.16.4. Similar to how JT65-HF, HB9HQX and MixW users are limited to 2.13.10 and XP users to 2.11.5.

There comes a point in time where old functionality is no longer available and that point has been reached with the Traditional Layout code.

de Laurie VK3AMA


locked Re: JTAlert 2.16.5 is available: Missing fields?

HamApps Support (VK3AMA)
 

On 11/05/2020 2:08 am, Richard Mead wrote:
I've not seen a mention so maybe it's just my install.
I no longer see the fields Continent or Country in the popup when I mouse over any call.
I reverted to 2.16.4 and they returned. Not a big deal but thought I'd mention...
73
Richard WB6NGC
Richard,

Tnx for the report. I can confirm this is a defect.
It has been corrected for the next release.

Sorry for the inconvenience.
de Laurie VK3AMA


locked Re: Zones Problem

HamApps Support (VK3AMA)
 

On 10/05/2020 12:58 pm, Dave Garber wrote:
I suspect an issue with adi from jtalert
It is not a JTAlert problem. If JTAlert shows zones in the log fields area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet sent. JTAlert deliberately does not send any Zone numbers if the value is NOT greater than zero. Similarly any data fields that are empty the corresponding adif field is simply not included in the adif packet. That is JTAlert only includes adif fields for non-empty and non-zero (> 1) data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA


locked Re: Welcome Back Laurie

HamApps Support (VK3AMA)
 

On 9/05/2020 7:53 am, WB8ASI Herb wrote:
Can't imagine your backlog.  Hope you had a good getaway.  Bet you're ready to start your next vacation.  73 Herb WB8ASI
Thanks Herb.

I was not officially back. I was in transit from my non-Internet QTH, spending some time at a family members house and wanted to check the unread messages and couldn't resist reply to some.

I am now back home and online again.

de Laurie VK3AMA


locked Re: JTAlert 2.16.5 Download

Jim N6VH
 

On 5/10/2020 10:15 AM, Robert T wrote:

Has anyone been able to download and successfully install ver 2.16.5 without their virus scan deleting the install saying it has a virus?

Bob, K2RET
_._,_._,_


Yes. Using Norton 360. I did get the message from Norton saying this is new, and not may users (or words to that effect), but all I had to do was click "Trust" and no problem.  This is a pretty standard message from Norton regarding JTAlert, but never a mention of a virus.

73,

Jim N6VH

3801 - 3820 of 33231