locked JTAlert 2.16.17 - cannot rebuild alert database


fum
 

Dear,

I am new to JTAlert

JTAlert 2.16.17 - cannot rebuild alert database

  • ticked "Enable Stadard ADIF File Logging"
  • created an own JTAlert.adi file
  • enable wanted grid alert
  • rebuild All
Log Scan - Adif File is running - but not changing nothing at all, no green lines appear
Wanted Grid shows: 0 of 32400 Grid Squares NOT Needed
I have around 3000 entries in the JTAlert.adi

I am lost!
anyone who might help me?
is there a special standard needed for the ADI-file?
ADI-check does not show any problems

Thank you
Tom

thank you very much


HamApps Support (VK3AMA)
 

On 3/04/2021 12:45 am, fum wrote:
I am new to JTAlert

JTAlert 2.16.17 - cannot rebuild alert database

  • ticked "Enable Stadard ADIF File Logging"
  • created an own JTAlert.adi file
  • enable wanted grid alert
  • rebuild All
Log Scan - Adif File is running - but not changing nothing at all, no green lines appear
Wanted Grid shows: 0 of 32400 Grid Squares NOT Needed
I have around 3000 entries in the JTAlert.adi

I am lost!
anyone who might help me?
is there a special standard needed for the ADI-file?
ADI-check does not show any problems

Thank you
Tom

Send me a copy of your adif file and I will check it.

Send the file to  vk3ama.ham.apps [at] gmail.com

de Laurie VK3AMA



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


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


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




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



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