locked JTA Throws Error on Restart after Crashing


Hasan Schiers N0AN
 

I'm getting this error:

I have restarted computer, same error. I have not tried reinstalling JTA yet. I assume I have a corrupted file of some sort?

Should I reinstall?

TIA, 73, N0AN
Hasan


HamApps Support (VK3AMA)
 

On 1/04/2019 4:37 am, Hasan Schiers N0AN wrote:
I'm getting this error:

I have restarted computer, same error. I have not tried reinstalling JTA yet. I assume I have a corrupted file of some sort?

Should I reinstall?

TIA, 73, N0AN
Hasan
No need to reinstall. The error indicates a problem with the ADIF import. Just OK the error message, then open the JTAlert Settings window and set the path to your ADIF file in the Logging -> ADIF section. After setting the path restart JTAlert.

de Laurie VK3AMA


Hasan Schiers N0AN
 

Super, will try soonest, on CAS-4B satellite pass now. Tnx so much Laurie
will report back

Hasan


On Sun, Mar 31, 2019 at 12:49 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 1/04/2019 4:37 am, Hasan Schiers N0AN wrote:
I'm getting this error:

I have restarted computer, same error. I have not tried reinstalling JTA yet. I assume I have a corrupted file of some sort?

Should I reinstall?

TIA, 73, N0AN
Hasan
No need to reinstall. The error indicates a problem with the ADIF import. Just OK the error message, then open the JTAlert Settings window and set the path to your ADIF file in the Logging -> ADIF section. After setting the path restart JTAlert.

de Laurie VK3AMA


Hasan Schiers N0AN
 

Laurie
What is the path to the adif logging ? I only have enabled "Enable Standard ADIF File Logging", I use QRZ for logging which I'm assuming is not related to this. So I don't know where  to enter the path or what the path is to the logging file you referenced. 

I'b being a bit thick
tnx
Hasan


On Sun, Mar 31, 2019 at 12:49 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 1/04/2019 4:37 am, Hasan Schiers N0AN wrote:
I'm getting this error:

I have restarted computer, same error. I have not tried reinstalling JTA yet. I assume I have a corrupted file of some sort?

Should I reinstall?

TIA, 73, N0AN
Hasan
No need to reinstall. The error indicates a problem with the ADIF import. Just OK the error message, then open the JTAlert Settings window and set the path to your ADIF file in the Logging -> ADIF section. After setting the path restart JTAlert.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 1/04/2019 5:52 am, Hasan Schiers N0AN wrote:
What is the path to the adif logging ? I only have enabled "Enable Standard ADIF File Logging", I use QRZ for logging which I'm assuming is not related to this. So I don't know where  to enter the path or what the path is to the logging file you referenced. 

I'b being a bit thick
tnx
Hasan
There is more to ADIF logging than simply enabling it, you have to tell JTAlert the location of your ADIF file. You must have done that in the past. The path is set on the same Settings section as the enable checkbox, "Logging -> Standard ADIF File" section. eg.
 
   
   

de Laurie VK3AMA


Hasan Schiers N0AN
 

c:\Users\Hasan Quad\AppData\Local\HamApps\N0AN\logs\JTAlertX\log.adi


That did it, Now that file is very small, so it can't be my months and months of
log data. It contains:

 <ADIF_VER:5>2.2.7
<ProgramID:8>JTAlertX
<ProgramVersion:6>2.13.0
<APP_JTAlertX_Created:23>2019/03/31 20:06:04 UTC
<EOH>

In the same directory there is a *.mdb file that is B4log.mdb that is more than a megabyte in size, I hope that is the full log that is used for alerts.

Thanks so much for your help. 73, N0AN

Hasan


On Sun, Mar 31, 2019 at 2:43 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 1/04/2019 5:52 am, Hasan Schiers N0AN wrote:
What is the path to the adif logging ? I only have enabled "Enable Standard ADIF File Logging", I use QRZ for logging which I'm assuming is not related to this. So I don't know where  to enter the path or what the path is to the logging file you referenced. 

I'b being a bit thick
tnx
Hasan
There is more to ADIF logging than simply enabling it, you have to tell JTAlert the location of your ADIF file. You must have done that in the past. The path is set on the same Settings section as the enable checkbox, "Logging -> Standard ADIF File" section. eg.
 
   
   

de Laurie VK3AMA


Hasan Schiers N0AN
 

Laurie,
When I look at alerts by band as far as what is wanted, it is all "wanted" I no longer see any states worked or dxcc worked...and I had many, so I assume I have to do something to get all the old data read into JTAlert?
TIA
Hasan


On Sun, Mar 31, 2019 at 3:14 PM Hasan Schiers N0AN via Groups.Io <hbasri.schiers6=gmail.com@groups.io> wrote:
c:\Users\Hasan Quad\AppData\Local\HamApps\N0AN\logs\JTAlertX\log.adi


That did it, Now that file is very small, so it can't be my months and months of
log data. It contains:

 <ADIF_VER:5>2.2.7
<ProgramID:8>JTAlertX
<ProgramVersion:6>2.13.0
<APP_JTAlertX_Created:23>2019/03/31 20:06:04 UTC
<EOH>

In the same directory there is a *.mdb file that is B4log.mdb that is more than a megabyte in size, I hope that is the full log that is used for alerts.

Thanks so much for your help. 73, N0AN

Hasan


On Sun, Mar 31, 2019 at 2:43 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 1/04/2019 5:52 am, Hasan Schiers N0AN wrote:
What is the path to the adif logging ? I only have enabled "Enable Standard ADIF File Logging", I use QRZ for logging which I'm assuming is not related to this. So I don't know where  to enter the path or what the path is to the logging file you referenced. 

I'b being a bit thick
tnx
Hasan
There is more to ADIF logging than simply enabling it, you have to tell JTAlert the location of your ADIF file. You must have done that in the past. The path is set on the same Settings section as the enable checkbox, "Logging -> Standard ADIF File" section. eg.
 
   
   

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 1/04/2019 7:13 am, Hasan Schiers N0AN wrote:
c:\Users\Hasan Quad\AppData\Local\HamApps\N0AN\logs\JTAlertX\log.adi


That did it, Now that file is very small, so it can't be my months and months of
log data. It contains:

 <ADIF_VER:5>2.2.7
<ProgramID:8>JTAlertX
<ProgramVersion:6>2.13.0
<APP_JTAlertX_Created:23>2019/03/31 20:06:04 UTC
<EOH>

In the same directory there is a *.mdb file that is B4log.mdb that is more than a megabyte in size, I hope that is the full log that is used for alerts.

Thanks so much for your help. 73, N0AN

Hasan
Ignore the B4Log.mdb file, it is not relevant when using any of the supported log types. It also is NOT your full log.

The path shown in the previous image I provided is just a default path, it is not necessarily the path you would have used previously. It appears you used the "Create New" button, you should use the "Select" button and then browse to the location where you ADIF file is stored. That location is defined by you and is not dictated by JTAlert. You need to locate your original ADIF file and set JTAlert to use that file.

When you used the "Create New" button, JTAlert would have warned you if there was an existing file. If there was an existing file, then likely that was your original ADIF file if you in the past had JTAlert create  a new file.

If you can't find your original ADIF file, just take an ADIF export from your logger and use that. If you don't use a logger, you could use a COPY of your WSJT-X adi log file.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 1/04/2019 7:18 am, Hasan Schiers N0AN wrote:
Laurie,
When I look at alerts by band as far as what is wanted, it is all "wanted" I no longer see any states worked or dxcc worked...and I had many, so I assume I have to do something to get all the old data read into JTAlert?
TIA
Hasan
See my most recent message.

Your getting all calls alerted as needed because your now using an empty ADIF file. This is because you created a new file rather than selecting your existing ADIF file. Only you know where your original ADIF file is located, it is unlikely to be in the default location shown in my last posted image.

de Laurie VK3AMA


Hasan Schiers N0AN
 

Laurie, sorry to put you through this...

OK, I searched for log.adi...it is not on the drive. 
I shut down JTA
I copied the wsjtx *.adi log to the directory that Enable Logging was pointing to.
I rename the wsjtx.adi log to log.adi
I started X and it showed it was reading in 9500 some record (roughly)
I then went to Scan and Rebuild....told it do to all, (as I usually do)
It ran, but produced on worked stations. 

So, while it seems to read the wsjtx*.adi log renamed, for some reason the data 
while being read in, isn't being "used" by the program.

Any other ideas? I even tried Create new, chose wsjtx.adi, let it it overwrite it,
exited program. Deleted the newly created wsjtx.adi, recopied wsjtx.adi from 
wsjtx and then started JTA. It acted the same way, the 9500 some records appear
to read in, but when I do Scan and Rebuild, nothing shows up in either state or dx count.

Ideas? Again, thanks for your patience.
Hasan


On Sun, Mar 31, 2019 at 3:33 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 1/04/2019 7:18 am, Hasan Schiers N0AN wrote:
Laurie,
When I look at alerts by band as far as what is wanted, it is all "wanted" I no longer see any states worked or dxcc worked...and I had many, so I assume I have to do something to get all the old data read into JTAlert?
TIA
Hasan
See my most recent message.

Your getting all calls alerted as needed because your now using an empty ADIF file. This is because you created a new file rather than selecting your existing ADIF file. Only you know where your original ADIF file is located, it is unlikely to be in the default location shown in my last posted image.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 1/04/2019 8:08 am, Hasan Schiers N0AN wrote:

OK, I searched for log.adi...it is not on the drive. 
I shut down JTA
I copied the wsjtx *.adi log to the directory that Enable Logging was pointing to.
I rename the wsjtx.adi log to log.adi
I started X and it showed it was reading in 9500 some record (roughly)
I then went to Scan and Rebuild....told it do to all, (as I usually do)
It ran, but produced on worked stations. 

So, while it seems to read the wsjtx*.adi log renamed, for some reason the data 
while being read in, isn't being "used" by the program.

Any other ideas? I even tried Create new, chose wsjtx.adi, let it it overwrite it,
exited program. Deleted the newly created wsjtx.adi, recopied wsjtx.adi from 
wsjtx and then started JTA. It acted the same way, the 9500 some records appear
to read in, but when I do Scan and Rebuild, nothing shows up in either state or dx count.

Ideas? Again, thanks for your patience.
Hasan

Your original adif log file may not have been named log.adi, it could be anything, JTAlert doesn't care. log.adi is the default name JTAlert uses if you get JTAlert to create a new empty adif log file, which is what you have done.

Using a copy of the WSJT-X adi log file is acceptable within reason. It is a very limited file in terms of the adif fields it supports. Your Scan and Rebuild didn't find any Stations to take off your State and DXCC wanted lists because you very likely have QSL confirmation types set (eg Card or LoTW or eQSL) for the scans and the WSJT-X adi log file doesn't contain any of these QSL fields. In this situation, the WSJT-X adi log file is only useful for worked stations as there are no QSOs in the log marked as QSL confirmed. You will not be able to update the different wanted lists based on any QSL confirmation type, worked only.

You really need to find your old log file. JTAlert would not have deleted it. Don't you have backups? Have you checked your Recycle Bin? Unless you can recover your old log file or create a new one from either your logger export (if you use one) or from a LoTW or eQSL download your will have to live with using the WSJT-X data.

de Laurie VK3AMA


Hasan Schiers N0AN
 

Success! I used a search tool in Total Commander. It took  a long time but it found log.adi in the Recycle Bin. I copied it to the location I had specified in JTAlert and restarted the program, Everything came up fine.

I would have found it yesterday, but apparently I had not let the search of the Recycle Bin run long enough (its own search). When I went back to Total Commander this morning, it found log.adi in the Recycle Bin in less than 4 min. All I needed to do was click on it and copy it to the desired location.

You can be sure I will keep a backup of the log file from now on! (without using my full computer backup).

Thanks so much, Laurie. BTW, I was not checking for any confirmed. I only had worked selected in the settings of JTA...and the original WSJTX-adi log would not work, it would read in, but it produced nothing. So, something is not right with the format of the wsjtx adi file in terms of being read by JTA

73, N0AN
Hasan


On Sun, Mar 31, 2019 at 7:09 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 1/04/2019 8:08 am, Hasan Schiers N0AN wrote:

OK, I searched for log.adi...it is not on the drive. 
I shut down JTA
I copied the wsjtx *.adi log to the directory that Enable Logging was pointing to.
I rename the wsjtx.adi log to log.adi
I started X and it showed it was reading in 9500 some record (roughly)
I then went to Scan and Rebuild....told it do to all, (as I usually do)
It ran, but produced on worked stations. 

So, while it seems to read the wsjtx*.adi log renamed, for some reason the data 
while being read in, isn't being "used" by the program.

Any other ideas? I even tried Create new, chose wsjtx.adi, let it it overwrite it,
exited program. Deleted the newly created wsjtx.adi, recopied wsjtx.adi from 
wsjtx and then started JTA. It acted the same way, the 9500 some records appear
to read in, but when I do Scan and Rebuild, nothing shows up in either state or dx count.

Ideas? Again, thanks for your patience.
Hasan

Your original adif log file may not have been named log.adi, it could be anything, JTAlert doesn't care. log.adi is the default name JTAlert uses if you get JTAlert to create a new empty adif log file, which is what you have done.

Using a copy of the WSJT-X adi log file is acceptable within reason. It is a very limited file in terms of the adif fields it supports. Your Scan and Rebuild didn't find any Stations to take off your State and DXCC wanted lists because you very likely have QSL confirmation types set (eg Card or LoTW or eQSL) for the scans and the WSJT-X adi log file doesn't contain any of these QSL fields. In this situation, the WSJT-X adi log file is only useful for worked stations as there are no QSOs in the log marked as QSL confirmed. You will not be able to update the different wanted lists based on any QSL confirmation type, worked only.

You really need to find your old log file. JTAlert would not have deleted it. Don't you have backups? Have you checked your Recycle Bin? Unless you can recover your old log file or create a new one from either your logger export (if you use one) or from a LoTW or eQSL download your will have to live with using the WSJT-X data.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 1/04/2019 9:33 pm, Hasan Schiers N0AN wrote:
BTW, I was not checking for any confirmed. I only had worked selected in the settings of JTA...and the original WSJTX-adi log would not work, it would read in, but it produced nothing. So, something is not right with the format of the wsjtx adi file in terms of being read by JTA

73, N0AN
Hasan
Hasan,

Good to hear your back working.

I'll investigate why the wsjt-x adi log did not work, it is standard adif so there should have been no problem. Please send me direct (not via this group) the wsjt-x adi log file you used.

de Laurie VK3AMA


Hasan Schiers N0AN
 

Tnx Laurie, will do, soonest
73, N0AN
Hasan


On Mon, Apr 1, 2019 at 6:25 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 1/04/2019 9:33 pm, Hasan Schiers N0AN wrote:
BTW, I was not checking for any confirmed. I only had worked selected in the settings of JTA...and the original WSJTX-adi log would not work, it would read in, but it produced nothing. So, something is not right with the format of the wsjtx adi file in terms of being read by JTA

73, N0AN
Hasan
Hasan,

Good to hear your back working.

I'll investigate why the wsjt-x adi log did not work, it is standard adif so there should have been no problem. Please send me direct (not via this group) the wsjt-x adi log file you used.

de Laurie VK3AMA


Laurie, VK3AMA
 


On 1/04/2019 9:33 pm, Hasan Schiers N0AN wrote:
I only had worked selected in the settings of JTA...and the original WSJTX-adi log would not work, it would read in, but it produced nothing. So, something is not right with the format of the wsjtx adi file in terms of being read by JTA

73, N0AN
Hasan

Hasan,

I received your wsjt-x adi log file.

The clue to why the JTAlert Scan & Rebuild "produced nothing" was in your email stating "but did not produce any values for States Worked...etc". As I previously indicated, the wsjt-x adi log file is very limited in the adif fields it supports. At the time, I was referring to QSL confirmation fields as I was thinking that was your issue. In addition to no QSL confirmation fields (which is expected), it also doesn't contain any State or DXCC fields. Your Scan & Rebuild subsequently didn't find any worked States or Countries as that data is not available in the wsjt-x adi log.

JTAlert does not attempt to determine the State, dxcc, etc, when the data is missing as that would add significantly to the processing time overhead of the adif import. The expectation is that the user-provided adif file contains the required fields needed for the users alerting needs. In most cases the user-provided adif file does contain the data when the adif is an export from the users Logger. ADIF logging is a way of getting QSOs into Loggers not supported by JTAlert.

The wsjt-x adi log file is suitable for basic Band/Mode worked B4 determination only.

My recommendation on using the wsjt-x adi log was a last ditched effort to recover some of your lost log.

de Laurie VK3AMA