Date   

locked Re: Worked Before

Barry <boat.anchor@...>
 

On Sat, Feb 22, 2020 at 07:34 PM, HamApps Support (VK3AMA) wrote:

What Band & Mode tracking do you have set for the Grid alert?
What mode is the logged QSO that is not being picked up by the Scan?
What QSL requirements do you have set for the Grid Scan?

de Laurie VK3AMA

Laurie
TVM
My log had the incorrect grid for him on 17M so it was being shown correctly.
He was wrkd B4 es I still needed his grid on 17M.
Problem solved.
best regards
Barry

 


locked Re: SQL file write error

Σric W4DXX
 

Laurie,
I am using DXbase for logging.  JTAlert is throwing the ADIF SQLite file write record failure.  Attached is a screen shot of the error message.  Dxbase receives it's info from JTDX, so it logs it ok.  JTAlert is the app that is not logging it to its internal file.  This only happens with TU5PCT and is repeatable regardless of band, etc.


locked Re: Worked Before

HamApps Support (VK3AMA)
 

On 23/02/2020 2:34 pm, HamApps Support (VK3AMA) via Groups.Io wrote:
not adding that Grid to the not worked list

Correction. That should read "
not adding that Grid to the no longer needed list"

Plus. Also worth checking that the on-air grid that alerted as needed is the same grid as recorded in your log for that Callsign. Perhaps he has changed grid since you last worked him.

de Laurie VK3AMA


locked Re: Worked Before

HamApps Support (VK3AMA)
 

On 23/02/2020 11:51 am, Barry via Groups.Io wrote:
I have worked UA0CA on 17 es 20 and both are confirmed.
I have run scan and save
I still see him as a wanted grid


When I check Alerts/Wanted Grid/Individual Bands/17 his grid is not in the list.
Any suggetions for what to check.
TVM
Barry

Barry,

If JTAlert is not adding that Grid to the not worked list it is because it is not finding any QSOs in your log that meet your Band/Mode tracking requirements or your QSL requirements.

Likely the QSOs in your log don't have a suitable QSL confirmation type matching what you have set for the Grid scan, or they are missing the grid. Possibly they are for a mode other than the current mode and you the Grid tracking set for by Mode. There are several possible causes.

What Band & Mode tracking do you have set for the Grid alert?
What mode is the logged QSO that is not being picked up by the Scan?
What QSL requirements do you have set for the Grid Scan?

de Laurie VK3AMA


locked Re: SQL file write error

HamApps Support (VK3AMA)
 

On 23/02/2020 1:51 pm, Σric W4DXX wrote:
I get a SQL file write error when trying to log TU5PCT.  It only happens with TU5PCT.  It logs it in JTDX and sends it to my logger but pops a file write error box when it does.
Guessing TU5 is not in the prefix database or something similar.

OM,

What logger are you using with JTAlert?
What is the exact text of the error message and what application is throwing the error?
Post a screen-capture of the error window (please not your entire desktop, just the error window and NO cell phone photos).

de Laurie VK3AMA


locked SQL file write error

Σric W4DXX
 

I get a SQL file write error when trying to log TU5PCT.  It only happens with TU5PCT.  It logs it in JTDX and sends it to my logger but pops a file write error box when it does.
Guessing TU5 is not in the prefix database or something similar.


locked Worked Before

Barry <boat.anchor@...>
 

I have worked UA0CA on 17 es 20 and both are confirmed.
I have run scan and save
I still see him as a wanted grid


When I check Alerts/Wanted Grid/Individual Bands/17 his grid is not in the list.
Any suggetions for what to check.
TVM
Barry


locked Re: Worked B4 Not Working

WB8ASI Herb
 

See attached.  It doesn't happen every time.  Shows my QSO with K0SMT smoothly successfully logged at 2320Z.   It's now 2345Z as I send this memo and he's still call CQ and not showing the as Worked B4, and still showing on my Decodes Window with B4 hidden.  Hope it helps.  Thanks.

On February 22, 2020 at 5:24 PM "Michael Black via Groups.Io" <mdblack98@...> wrote:

You're not specifying any of these flags in JTAlert, are you?  And you are looking for the SQLITE_BUSY return?

The threading mode for an individual database connection is determined by flags given as the third argument to  sqlite3_open_v2() . The  SQLITE_OPEN_NOMUTEX  flag causes the database connection to be in the multi-thread mode and the  SQLITE_OPEN_FULLMUTEX  flag causes the connection to be in serialized mode. If neither flag is specified or if  sqlite3_open()  or  sqlite3_open16()  are used instead of  sqlite3_open_v2() , then the default mode determined by the compile-time and start-time settings is used.




On Saturday, February 22, 2020, 04:11:56 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 23/02/2020 8:57 am, Michael Black via Groups.Io wrote:
I don't think the database will matter...I haven't tested MySQL with V2 but with V1 it was not any better than SQLite.

The problem with V2 is multi-fold....#1 they parse all the awards they have which is dog slow...and you can't delete the awards you don't care about  #2 They have LINQ data stored in the database so indexing the columns doesn't help things at all.  Queries that should take ms take seconds.  The same things in V1 are much faster.

V2 wasn't getting many beta testers so they opened it up and are fixing bugs now.

de Mike W9MDB

Mike,

My reason for the database type question is I am thinking there may be a database locking issue preventing JTAlert from reading the log to get the B4 status. I don't have any evidence of this, I am just gathering data.

The non-index-able data stored in the Log4OM2 log is Json text data, not Linq, you will find. This is a performance problem, especially with large QSOs logs. It caused a lot of coding workarounds in JTAlert to achieve the simplest of sql queries.

de Laurie VK3AMA

 

 


locked Re: Worked B4 Not Working

Michael Black
 

You're not specifying any of these flags in JTAlert, are you?  And you are looking for the SQLITE_BUSY return?

The threading mode for an individual database connection is determined by flags given as the third argument to sqlite3_open_v2(). The SQLITE_OPEN_NOMUTEX flag causes the database connection to be in the multi-thread mode and the SQLITE_OPEN_FULLMUTEX flag causes the connection to be in serialized mode. If neither flag is specified or if sqlite3_open() or sqlite3_open16() are used instead of sqlite3_open_v2(), then the default mode determined by the compile-time and start-time settings is used.




On Saturday, February 22, 2020, 04:11:56 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 23/02/2020 8:57 am, Michael Black via Groups.Io wrote:
I don't think the database will matter...I haven't tested MySQL with V2 but with V1 it was not any better than SQLite.

The problem with V2 is multi-fold....#1 they parse all the awards they have which is dog slow...and you can't delete the awards you don't care about  #2 They have LINQ data stored in the database so indexing the columns doesn't help things at all.  Queries that should take ms take seconds.  The same things in V1 are much faster.

V2 wasn't getting many beta testers so they opened it up and are fixing bugs now.

de Mike W9MDB

Mike,

My reason for the database type question is I am thinking there may be a database locking issue preventing JTAlert from reading the log to get the B4 status. I don't have any evidence of this, I am just gathering data.

The non-index-able data stored in the Log4OM2 log is Json text data, not Linq, you will find. This is a performance problem, especially with large QSOs logs. It caused a lot of coding workarounds in JTAlert to achieve the simplest of sql queries.

de Laurie VK3AMA


locked Re: Worked B4 Not Working

HamApps Support (VK3AMA)
 

On 23/02/2020 8:57 am, Michael Black via Groups.Io wrote:
I don't think the database will matter...I haven't tested MySQL with V2 but with V1 it was not any better than SQLite.

The problem with V2 is multi-fold....#1 they parse all the awards they have which is dog slow...and you can't delete the awards you don't care about  #2 They have LINQ data stored in the database so indexing the columns doesn't help things at all.  Queries that should take ms take seconds.  The same things in V1 are much faster.

V2 wasn't getting many beta testers so they opened it up and are fixing bugs now.

de Mike W9MDB

Mike,

My reason for the database type question is I am thinking there may be a database locking issue preventing JTAlert from reading the log to get the B4 status. I don't have any evidence of this, I am just gathering data.

The non-index-able data stored in the Log4OM2 log is Json text data, not Linq, you will find. This is a performance problem, especially with large QSOs logs. It caused a lot of coding workarounds in JTAlert to achieve the simplest of sql queries.

de Laurie VK3AMA


locked Re: nEED CVS 30 MDG FILE NEEDED

HamApps Support (VK3AMA)
 

On 23/02/2020 8:49 am, Dave Tucker Nu4N wrote:
The hamclubs website  does not list a membership list for jT Alert
I never said it did. But it does host 30mdg data files. Likely one of those formats is compatible or can be easily modified using a text editor.
There is nothing exotic about the JTAlert format file, just a comma separated list of callsigns. It shouldn't be too hard for you to create.


de Laurie VK3AMA


locked Re: Worked B4 Not Working

Michael Black
 

I don't think the database will matter...I haven't tested MySQL with V2 but with V1 it was not any better than SQLite.

The problem with V2 is multi-fold....#1 they parse all the awards they have which is dog slow...and you can't delete the awards you don't care about  #2 They have LINQ data stored in the database so indexing the columns doesn't help things at all.  Queries that should take ms take seconds.  The same things in V1 are much faster.

V2 wasn't getting many beta testers so they opened it up and are fixing bugs now.

de Mike W9MDB




On Saturday, February 22, 2020, 03:46:19 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 23/02/2020 8:33 am, WB8ASI Herb wrote:
Yes, I get the logging confirmation right away (less than 10 sec).  I have it set to check for 10sec, and seems to be working fine.   What I do see is Log4OM taking a long time (sometimes 1-2 minutes) to provide the proper color showing confirmed, and confirmed band on its main cluster page.  This occurs with many spots, not just the one being logged.  I don't think the Log4OM delay is related to the JTAlert delay, but you would know best.  Thanks, Herb WB8ASI

Herb,

The 1-2 minutes delay your seeing in Log4OM2 may be part of the cause for the B4 non-display.
What database type are you using with your Log4OM2 log, SQLite or MySQL?

de Laurie VK3AMA


locked Re: Worked B4 Not Working

WB8ASI Herb
 

Using Log4OM V2 2.3.0.0 with SQLite file.  

On February 22, 2020 at 4:46 PM "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...> wrote:

On 23/02/2020 8:33 am, WB8ASI Herb wrote:
Yes, I get the logging confirmation right away (less than 10 sec).  I have it set to check for 10sec, and seems to be working fine.   What I do see is Log4OM taking a long time (sometimes 1-2 minutes) to provide the proper color showing confirmed, and confirmed band on its main cluster page.  This occurs with many spots, not just the one being logged.  I don't think the Log4OM delay is related to the JTAlert delay, but you would know best.  Thanks, Herb WB8ASI

Herb,

The 1-2 minutes delay your seeing in Log4OM2 may be part of the cause for the B4 non-display.
What database type are you using with your Log4OM2 log, SQLite or MySQL?

de Laurie VK3AMA


 


locked Re: nEED CVS 30 MDG FILE NEEDED

 

The hamclubs website  does not list a membership list for jT Alert

thanks--
DAVE NU4N


locked Re: Worked B4 Not Working

HamApps Support (VK3AMA)
 

On 23/02/2020 8:33 am, WB8ASI Herb wrote:
Yes, I get the logging confirmation right away (less than 10 sec).  I have it set to check for 10sec, and seems to be working fine.   What I do see is Log4OM taking a long time (sometimes 1-2 minutes) to provide the proper color showing confirmed, and confirmed band on its main cluster page.  This occurs with many spots, not just the one being logged.  I don't think the Log4OM delay is related to the JTAlert delay, but you would know best.  Thanks, Herb WB8ASI

Herb,

The 1-2 minutes delay your seeing in Log4OM2 may be part of the cause for the B4 non-display.
What database type are you using with your Log4OM2 log, SQLite or MySQL?

de Laurie VK3AMA


locked Re: Worked B4 Not Working

HamApps Support (VK3AMA)
 

On 22/02/2020 4:11 am, Joseph Hurd wrote:
I have noted the same issue before. Sometimes a station I just worked will immediately show as "B-4" on the next decode of their call. Intermittent problem. I just do a work around by shutting down WSJT, shutting down JTAlert, then restarting them. I now do this every time I update my wanted DXCC countries & States in JTAlert, so I don;t chase stations I don't need. I am running latest version of JTA.

What logger are you using with JTAlert? Is it Log4OM2 also?

de Laurie VK3AMA


locked Re: Worked B4 Not Working

WB8ASI Herb
 

Yes, I get the logging confirmation right away (less than 10 sec).  I have it set to check for 10sec, and seems to be working fine.   What I do see is Log4OM taking a long time (sometimes 1-2 minutes) to provide the proper color showing confirmed, and confirmed band on its main cluster page.  This occurs with many spots, not just the one being logged.  I don't think the Log4OM delay is related to the JTAlert delay, but you would know best.  Thanks, Herb WB8ASI

On February 22, 2020 at 4:15 PM "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...> wrote:

On 21/02/2020 3:17 pm, WB8ASI Herb wrote:
Since upgrading to JTA 2.15.10 and Log4OM V2, the Worked B4 Callsigns are not updating upon logging.  The logging is fine.  I just worked KI5FTP and he's in the log.  Does not show him as a B4 contact in JTAlert.  Used to be the B4 update was immediate. (he should be Gray Color for me, and not appear on my Decodes Window based on my colors and filters, yet he is still there, and seems to be staying there).  I shut down Log4OM and restarted and same thing.  I shut down JTAlert and restarted and all is well.  KI5FTP is now B4 in color and off the Decodes window.  Sorry Laurie for another small clitch.  Hope it's not just operator error again. 73, Herb WB8ASI

Herb,

Did JTAlert produce a logging success confirmation message or an unable to confirm logging message?

How long, approximately, does it take for the QSO to appear in Log4OM2 after the QSO is logged in WSJT-X?

de Laurie VK3AMA


 


locked Re: Worked B4 Not Working

HamApps Support (VK3AMA)
 

On 21/02/2020 3:17 pm, WB8ASI Herb wrote:
Since upgrading to JTA 2.15.10 and Log4OM V2, the Worked B4 Callsigns are not updating upon logging.  The logging is fine.  I just worked KI5FTP and he's in the log.  Does not show him as a B4 contact in JTAlert.  Used to be the B4 update was immediate. (he should be Gray Color for me, and not appear on my Decodes Window based on my colors and filters, yet he is still there, and seems to be staying there).  I shut down Log4OM and restarted and same thing.  I shut down JTAlert and restarted and all is well.  KI5FTP is now B4 in color and off the Decodes window.  Sorry Laurie for another small clitch.  Hope it's not just operator error again. 73, Herb WB8ASI

Herb,

Did JTAlert produce a logging success confirmation message or an unable to confirm logging message?

How long, approximately, does it take for the QSO to appear in Log4OM2 after the QSO is logged in WSJT-X?

de Laurie VK3AMA


locked Re: M5JG shows strange information from QRZ.com when I worked him

HamApps Support (VK3AMA)
 

On 22/02/2020 12:53 pm, Jim Spears wrote:
NY stuffed into the state field is also interesting.  I did work a NY station followed by AR, NC and AL stations - all of which are logged correctly.  the next station was VK9NR who got a state of NY then M4JPG who we have discussed followed by 4 additional non-US stations all of which got NY as the state.
Jim,

For these non-US Calls, do you recall if the JTAlert State field in the log fields area was showing "NY" or was it blank? If it is blank, than JTAlert should not be logging any State value.

What Logger are you using with JTAlert?

At this time, I have been unable to reproduce the US State logging for non-US calls in my tests.

de Laurie VK3AMA


locked Re: nEED CVS 30 MDG FILE NEEDED

Laurie, VK3AMA
 

On 23/02/2020 7:39 am, Dave Tucker Nu4N wrote:
 i NEED A CSV 30MDG FILE TO UPLOAD TO THE WANTED CALLSIGN SECTION.Does anyone have a csv like this??
tnx 73
--
DAVE NU4N
Try here http://www.hamclubs.info/

de Laurie VK3AMA