Date   

locked Re: Slow Decode window

Barry
 

Hi Mike,
CPU i7 970 @ 3GHz
DXkeeper


locked Re: Slow Decode window

JTAlert Support (VK3AMA)
 

On 4/04/2021 2:43 pm, Jim Cooper wrote:
Bottom margin shows  23,979 Recs (4.8MB) 
and  View : 2000 Recs
Try dropping the max view records.

de Laurie VK3AMA


locked Re: Slow Decode window

Jim Cooper
 

Actually, I have been having a similar problem
for quite a while, but I have not considered it
annoying enough to report until things settled
a bit ... my Decodes 2.16.17 will go along just
fine until it doesn't ... when I look for something
and don't see it, and then look at the time column
it had stopped some time before that -- it seems
to be random; that is, I have not been able to
pin it down to any particular circumstance or action
at which it stops.

I simple 'upper right X' it and F10 restart it, and
it comes back up with ALL the data that should have
been displayed after it stopped.

In fact, right now the UTC time is 04:40:02 and
the last displayed entry in Decodes is at 04:29:52 [FT4].

Bottom margin shows 23,979 Recs (4.8MB)
and View : 2000 Recs

I restarted it and it shows 24,152 Recs
AND all the records between 04:29:52 and restart
are now displayed.

w2jc


On 4 Apr 2021 at 14:10, HamApps Support (VK3AMA)
wrote:

On 4/04/2021 1:26 pm, Barry wrote:
Been using JTAlert for a while now and I have a problem with the
Decode window not updating for a long time (well over the 10second
mark) and some times only a few call signs?
When there are lots of stations it just stops working.
Things like clicking the view button it is slow to bring the menu
up,
than click the clear and it either does it or locks up, at this
stage
I need to close and restart the decode window.
I also see that my CPU is running at around 20% when the decode
window
is active and 7% when not turned on?
I have 21,400 contacts.
I have rebuilt the logs.
I have put old versions on with no change.
I have played with the settings.
I have 2.16.17 installed
I am running windows 10

Any help please.

VK2AHE Barry
How many records does your Decodes database currently hold and what
is
its physical size?
Look at the status bar.
eg from my Decodes window


de Laurie VK3AMA








locked Re: Slow Decode window

JTAlert Support (VK3AMA)
 

On 4/04/2021 1:26 pm, Barry wrote:
Been using JTAlert for a while now and I have a problem with the Decode window not updating for a long time (well over the 10second mark) and some times only a few call signs?
When there are lots of stations it just stops working.
Things like clicking the view button it is slow to bring the menu up, than click the clear and it either does it or locks up, at this stage I need to close and restart the decode window.
I also see that my CPU is running at around 20% when the decode window is active and 7% when not turned on?
I have 21,400 contacts.
I have rebuilt the logs.
I have put old versions on with no change.
I have played with the settings.
I have 2.16.17 installed
I am running windows 10

Any help please.

VK2AHE Barry

How many records does your Decodes database currently hold and what is its physical size?
Look at the status bar.
eg from my Decodes window


de Laurie VK3AMA



locked Re: Slow Decode window

Michael Black
 

What logger are you using?

What CPU do you have?

Mike W9MDB




On Saturday, April 3, 2021, 10:40:48 PM CDT, Barry <barry@...> wrote:


Hi All,
Been using JTAlert for a while now and I have a problem with the Decode window not updating for a long time (well over the 10second mark) and some times only a few call signs?
When there are lots of stations it just stops working.
Things like clicking the view button it is slow to bring the menu up, than click the clear and it either does it or locks up, at this stage I need to close and restart the decode window.
I also see that my CPU is running at around 20% when the decode window is active and 7% when not turned on?
I have 21,400 contacts.
I have rebuilt the logs.
I have put old versions on with no change.
I have played with the settings.
I have 2.16.17 installed
I am running windows 10

Any help please.

VK2AHE Barry


locked Slow Decode window

Barry
 

Hi All,
Been using JTAlert for a while now and I have a problem with the Decode window not updating for a long time (well over the 10second mark) and some times only a few call signs?
When there are lots of stations it just stops working.
Things like clicking the view button it is slow to bring the menu up, than click the clear and it either does it or locks up, at this stage I need to close and restart the decode window.
I also see that my CPU is running at around 20% when the decode window is active and 7% when not turned on?
I have 21,400 contacts.
I have rebuilt the logs.
I have put old versions on with no change.
I have played with the settings.
I have 2.16.17 installed
I am running windows 10

Any help please.

VK2AHE Barry


locked Re: Broken QSOs

Jim Cooper
 

On 3 Apr 2021 at 14:49, Joe Subich, W4TV wrote:

> On 2021-04-03 9:30 AM, Curt Bowles wrote:
>
> > 2.   Did QRM or some other software issue on my end fail to
> > catch the 73 and therefore not log the contact?
>
> WSJTX and JTAlert will prompt you to
> log the QSO when 1) You *receive*
> "RRR", 2) You *receive* "RR73", 3)
> you *send* "RRR" or 4) you *send*
> RR73.

ONLY if you have checked the setting box
on the Reporting tab of WSJT-X

graphic


  


locked Re: Broken QSOs

Joe Subich, W4TV
 

On 2021-04-03 9:30 AM, Curt Bowles wrote:

2. Did QRM or some other software issue on my end fail to catch
the 73 and therefore not log the contact?
WSJTX and JTAlert will prompt you to log the QSO when 1) You *receive*
"RRR", 2) You *receive* "RR73", 3) you *send* "RRR" or 4) you *send*
RR73.

These four cases are the correct definitions of a "completed QSO".

There *IS NO REQUIREMENT* to send/receive 73 (acknowledge your QSO
partner's acknowledgement of your report).

If you delay logging the QSO until you have received "73" and never
receive that "73", the "broken QSO" is on you - not WSJTX/JTAlert.

73,

... Joe, W4TV


On 2021-04-03 9:30 AM, Curt Bowles wrote:
Good Day:
I am using WSJT-x V2.3.0 & JTAlert 2.16.17 with DXLab. It is set up for logging and works just fine on all normal QSO’s. I have been using this setup for a year but I am still learning. I hope I can describe the use case correctly.
Occasionally I work a DX and get a broken QSO…. That is I’m guess I may not have receive the 73 basically the auto sequence does not finished so obviously the QSO doesn’t get log.
When I sync eQSL or LOTW with DXKeeper. I will see a FT8 QSO not found as the broken QSO did not get logged. So then I have to go ALL.txt and look up the info…! And hand log the QSO after the fact if I consider that is legit (Broken QSO)!
1.   So is this actually considered a legit QSO?
2.   Did QRM or some other software issue on my end fail to catch the 73 and therefore not log the contact?
3.   Is there a way to force logging of a broken QSO if you note the sequence is not completing?
4.   Last question: Is it ok to occasionally clean out (delete) entries in the ALL.TXT file to reduce its size?
--
Curt VE3ZN


locked Broken QSOs

Curt Bowles
 

Good Day:

I am using WSJT-x V2.3.0 & JTAlert 2.16.17 with DXLab. It is set up for logging and works just fine on all normal QSO’s. I have been using this setup for a year but I am still learning. I hope I can describe the use case correctly.

Occasionally I work a DX and get a broken QSO…. That is I’m guess I may not have receive the 73 basically the auto sequence does not finished so obviously the QSO doesn’t get log.

When I sync eQSL or LOTW with DXKeeper. I will see a FT8 QSO not found as the broken QSO did not get logged. So then I have to go ALL.txt and look up the info…! And hand log the QSO after the fact if I consider that is legit (Broken QSO)!

1.   So is this actually considered a legit QSO?

2.   Did QRM or some other software issue on my end fail to catch the 73 and therefore not log the contact?

3.   Is there a way to force logging of a broken QSO if you note the sequence is not completing?

4.   Last question: Is it ok to occasionally clean out (delete) entries in the ALL.TXT file to reduce its size?

--
Curt VE3ZN


locked Re: JTAlert 2.16.17 - cannot rebuild alert database

fum
 

Hi again,

another good hint:
I was using an old version of ADIF Master - 2.7
now upgraded to 3.3 - the error message is gone

tnx a lot


Am 02.04.2021 um 22:20 schrieb HamApps Support (VK3AMA):

On 3/04/2021 7:01 am, Michael Black via groups.io wrote:
So all programs are supposed to accept MODE:PSK31 and accept and output MODE:MFSK SUBMODE:PSK31 for ADIF 3.0.4 and higher compatbility.


FYI, JTAlert supports adif depreciated mode importing for the likes of PSK, FT4, FST4, Q65, etc. It will accept either the old <MODE> or new <SUBMODE> definitions.

The program used to generate the .log file in the posted message appears to be ignoring legacy mode definitions.
I don't know that program is at this time.


de Laurie VK3AMA





locked Re: JTAlert 2.16.17 - cannot rebuild alert database

fum
 

Hi Laurie,

the QSL-story was the right hint.

thank you - it is working now

vy73 de DF8IJ, Tom

Am 02.04.2021 um 21:53 schrieb HamApps Support (VK3AMA):

On 3/04/2021 1:51 am, fum wrote:
Hi Laurie,

tnx fr the quick response
see attachment

Tom, DF8IJ
Tom,

I can't find any fault with your adif file. Using it I got 616 unique grid squares not needed after running the rebuild operation.

I do note that the file does not contain any QSL confirmation fields (card, Lotw or Eqsl), so I had to set the Gridsquares rebuild to not look for any QSL confirmations. I suspect that you have one or more confirmation types set for the Gridsquare rebuild, is that the case? If so that would explain why you get zero results after the rebuild operation.

Also, the JTAlert.adi.log file you provided, where did that come from, it is not one of the JTAlert files? The reason I ask is that it contains many entries reporting "Invalid 'MODE' value:", for entries with "<MODE:5>PSK31". That error is clearly wrong, PSK31 is a valid mode. The program that is incorrectly reporting that error, if it is being used to produce your final adif file for JTAlert will result in an incomplete adif file missing many previous QSOs and they will not be present for JTAlert during the Alert Database Rebuild.

de Laurie VK3AMA



locked Re: JTAlert 2.16.17 - cannot rebuild alert database

JTAlert Support (VK3AMA)
 

On 3/04/2021 7:01 am, Michael Black via groups.io wrote:
So all programs are supposed to accept MODE:PSK31 and accept and output MODE:MFSK SUBMODE:PSK31 for ADIF 3.0.4 and higher compatbility.


FYI, JTAlert supports adif depreciated mode importing for the likes of PSK, FT4, FST4, Q65, etc. It will accept either the old <MODE> or new <SUBMODE> definitions.

The program used to generate the .log file in the posted message appears to be ignoring legacy mode definitions.
I don't know that program is at this time.


de Laurie VK3AMA




locked Re: JTAlert 2.16.17 - cannot rebuild alert database

Michael Black
 

PSK31 is a valid mode for ADIF 2.1 through ADFI 3.0.3

ADIF 3.0.4 introduced submode.

So all programs are supposed to accept MODE:PSK31 and accept and output MODE:MFSK SUBMODE:PSK31 for ADIF 3.0.4 and higher compatbility.

Mike W9MDB




On Friday, April 2, 2021, 02:53:52 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 3/04/2021 1:51 am, fum wrote:
Hi Laurie,

tnx fr the quick response
see attachment

Tom, DF8IJ
Tom,

I can't find any fault with your adif file. Using it I got 616 unique grid squares not needed after running the rebuild operation.

I do note that the file does not contain any QSL confirmation fields (card, Lotw or Eqsl), so I had to set the Gridsquares rebuild to not look for any QSL confirmations. I suspect that you have one or more confirmation types set for the Gridsquare rebuild, is that the case? If so that would explain why you get zero results after the rebuild operation.

Also, the JTAlert.adi.log file you provided, where did that come from, it is not one of the JTAlert files? The reason I ask is that it contains many entries reporting "Invalid 'MODE' value:", for entries with "<MODE:5>PSK31". That error is clearly wrong, PSK31 is a valid mode. The program that is incorrectly reporting that error, if it is being used to produce your final adif file for JTAlert will result in an incomplete adif file missing many previous QSOs and they will not be present for JTAlert during the Alert Database Rebuild.

de Laurie VK3AMA


locked Re: "wanted" button in jtdx

JTAlert Support (VK3AMA)
 

On 3/04/2021 2:21 am, Matthias Bellmann wrote:
with marked "wanted"button in jtdx and callsign in the "callsign"-line the selected callsigns are displayed in the rx-window. So i expected and so it happens.
BUT when entering prefix or country in the appropriate line nothing happens. jtdx user guide gives no explanation. Whar must i do to select an a particular prefix oder country?
 
Happy easter to all of you
73 Matthias DK4WD

Wrong group. Try posting to the official JTDX support group @ https://JTDX.groups.io

de Laurie VK3AMA


locked Re: Show DXCC country

JTAlert Support (VK3AMA)
 

On 3/04/2021 4:33 am, vo1lm9@... wrote:
I have JT Alert 2.16.17  How do I get the DXCC country in the Rx window?

DXCC Name visibility is controlled by the JTAlert "View -> Callsign Display Lines -> Show DXCC Names" menu.

   

de Laurie VK3AMA


locked Re: JTAlert 2.16.17 - cannot rebuild alert database

JTAlert Support (VK3AMA)
 

On 3/04/2021 1:51 am, fum wrote:
Hi Laurie,

tnx fr the quick response
see attachment

Tom, DF8IJ
Tom,

I can't find any fault with your adif file. Using it I got 616 unique grid squares not needed after running the rebuild operation.

I do note that the file does not contain any QSL confirmation fields (card, Lotw or Eqsl), so I had to set the Gridsquares rebuild to not look for any QSL confirmations. I suspect that you have one or more confirmation types set for the Gridsquare rebuild, is that the case? If so that would explain why you get zero results after the rebuild operation.

Also, the JTAlert.adi.log file you provided, where did that come from, it is not one of the JTAlert files? The reason I ask is that it contains many entries reporting "Invalid 'MODE' value:", for entries with "<MODE:5>PSK31". That error is clearly wrong, PSK31 is a valid mode. The program that is incorrectly reporting that error, if it is being used to produce your final adif file for JTAlert will result in an incomplete adif file missing many previous QSOs and they will not be present for JTAlert during the Alert Database Rebuild.

de Laurie VK3AMA


locked Show DXCC country

David McLennon
 

I have JT Alert 2.16.17  How do I get the DXCC country in the Rx window?


locked Re: Error msg

Lawrence Godek
 

THis happened this morning when i opened up JTAlert to work T6AA.  Same line number , 39738, all the rest of the msg is the same.  Didn't operate yesterday so no occasions.

Larry W0OGH


On 3/31/2021 12:42 PM, HamApps Support (VK3AMA) wrote:
On 30/03/2021 10:37 am, Lawrence Godek wrote:
---------------------------
AutoIt Error
---------------------------
Line 39738  (File "C:\Program Files (x86)\HamApps\JTAlert 2.16.17\JTAlert.exe"):


Error: Array variable has incorrect number of subscripts or subscript dimension range exceeded.
---------------------------
OK  �
---------------------------

I started getting this error msg a week or so ago.  Just out of the clear blue sky.  Have not made any changes in software to the computer which is a Win 7 Pro, been working just fine.  Log4OM 2.11.0.0, WSJT 2.2.2 and of course JTAlert 2.16.17.  I'll be working stations and all of a sudden it pops up and the current and subsequent stations don't get logged.  Course i have to close the APP and then restart it but then shortly thereafter  i get the same error again.  WHOTS UP?  Reboots don't clear the problem it just keeps reoccurring.

Larry W0OGH

Is it the same error line number each time or does it vary?

How frequent are these crashes? Are they every time JTAlert is run or less often?

2.16.17 has been very stable without serious defects and is part of the reason there has not been a public update for 4 months.


While, you claim no software changes, that is very unlikely unless you're running Windows without Virus protection or non-updated protection software. Protection software is frequently updated, typically on a daily basis. Perhaps it has decided to take a dislike to JTAlert and is interfering.

You could try downgrading JTAlert to an earlier version (.16, .15 & .14 are still available at https://hamapps.com/JTAlert/)

de Laurie VK3AMA


locked "wanted" button in jtdx

Matthias Bellmann
 

with marked "wanted"button in jtdx and callsign in the "callsign"-line the selected callsigns are displayed in the rx-window. So i expected and so it happens.
BUT when entering prefix or country in the appropriate line nothing happens. jtdx user guide gives no explanation. Whar must i do to select an a particular prefix oder country?
 
Happy easter to all of you
73 Matthias DK4WD


locked Re: JT-Alert 2.16.17 Crashes on both my computers. #JTDX

tobbeerlandsson@...
 
Edited

On Thu, Apr 1, 2021 at 10:10 PM, HamApps Support (VK3AMA) wrote:
I did test to temporarily changing it to a different device then changing it back...same result. 

6281 - 6300 of 39820