Topics

locked Logging failures do not update worked before information


g4wjs
 

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.


g4wjs
 

On 09/05/2020 21:22, 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 again Laurie,

a useful option for this could be a "Retry" button on the popup message about the logging failure.



--
73
Bill
G4WJS.


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


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.


Michael Black
 

Bill...how many QSOs do you have and how big is your database?

I ran into a couple of users there their mdb file had grown way too big and we had to backup/restore/compact and their update rates improved considerably.
There's a 2GB limit on MDB files too.

de Mike W9MDB




On Monday, May 11, 2020, 06:37:38 AM CDT, g4wjs <bill.8@...> wrote:


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.


HamApps Support (VK3AMA)
 

On 11/05/2020 9:37 pm, g4wjs wrote:

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

Bill,

Do you have DXKeeper set to auto-upload new QSOs to one or more online-logbooks? If so, that is a likely cause of the occasional extended logging times. That has been experience by JTAlert/DXKeeper users in the past.

Regarding a "Retry" button, that would seem to be the most sensible if it wasn't' for the code I have to work with. All the logging code is in the main JTAlert executable and runs on the UI thread. A Retry will involve a database access and a timeout value (if the lookup was unsuccessful), both of which will block the main thread. I am hesitant to add further blocking code. I will give it some thought.

de Laurie VK3AMA


WB8ASI Herb
 

Laurie,  I don't know about a Retry, but seems it might be possible.  There is the Last QSO Log that it tells us it's there.  I have stumbled around in the past and somehow got it to get it back in the log.  Usually it's easier for me to just enter the info into the log from the still visible screen, but I can't remember how to retrieve it from the Last QSO Log, but that's gotta be a clue for a Retry.  Thanks again. 73 Herb WB8ASI  Can't sleep.

On May 12, 2020 at 2:22 AM "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...> wrote:

On 11/05/2020 9:37 pm, g4wjs wrote:

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

Bill,

Do you have DXKeeper set to auto-upload new QSOs to one or more online-logbooks? If so, that is a likely cause of the occasional extended logging times. That has been experience by JTAlert/DXKeeper users in the past.

Regarding a "Retry" button, that would seem to be the most sensible if it wasn't' for the code I have to work with. All the logging code is in the main JTAlert executable and runs on the UI thread. A Retry will involve a database access and a timeout value (if the lookup was unsuccessful), both of which will block the main thread. I am hesitant to add further blocking code. I will give it some thought.

de Laurie VK3AMA


 


g4wjs
 

On 12/05/2020 07:22, HamApps Support (VK3AMA) wrote:
On 11/05/2020 9:37 pm, g4wjs wrote:

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

Bill,

Do you have DXKeeper set to auto-upload new QSOs to one or more online-logbooks? If so, that is a likely cause of the occasional extended logging times. That has been experience by JTAlert/DXKeeper users in the past.

Regarding a "Retry" button, that would seem to be the most sensible if it wasn't' for the code I have to work with. All the logging code is in the main JTAlert executable and runs on the UI thread. A Retry will involve a database access and a timeout value (if the lookup was unsuccessful), both of which will block the main thread. I am hesitant to add further blocking code. I will give it some thought.

de Laurie VK3AMA

Hi Laurie,

thanks for that, the online lookups are most probably the issue as I have a WiFi connection in the shack which is a bit QRP. No problem on the issues with implementing a "Retry" button, I had assumed that as the failure message doesn't time out that the required code to retry the logbook lookup was easily accessible, but if that is not the case I fully understand the issues. Since no one else has chipped in with similar requests, I am fine with just clearing the B4 cache when this happens. Normally it is pretty obvious where a station is running a frequency and continues to call after a QSO, I have to be pretty distracted not to notice that I have just worked them.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


David De Coons
 

Here’s something to check.
Myfriend was having intermittent issues using a Lenovo i5 laptop. We found his CPU running @ 100% and memory around 70%. A little digging found he had two hardware issues.

1) he was running Win 10 woth only 4 GB ram. Upgraded to 12 GB. CPU still at 100% but memory better.

2) he was using a USB to HDMI adapter plugged into a USB 2.0 port for an external 36” TV as a monitor. This was the bottleneck. The laptop has a mini display port so he replaced the adapter with a mini display port to HDMI cable. CPU now around 30% and memory around 30%.

Last, yesterday he cloned the laptop drive to a solid state drive (they are cheap now here in U.S.). He put the SDD drive in the laptop in place of the original drive. Now everything is running MUCH faster.

For HRD Logbook we converted his log from Access to SQL Lite using MariaDB. With larger logs (mine has 20,000 contacts) it speeds logbook database queries up.

And last comment. For the reply on failed to log QSOs you can click on log QSO in WSJT-X as long as you haven’t started the next QSO. Just remember to check the start time.

Some of the intermittent logging issues may be due to CPU or memory bottlenecks in the PC. Not saying al are due to this but worth checking.

73
Dave wo2x


On May 12, 2020, at 6:37 AM, g4wjs <bill.8@...> wrote:


On 12/05/2020 07:22, HamApps Support (VK3AMA) wrote:
On 11/05/2020 9:37 pm, g4wjs wrote:

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

Bill,

Do you have DXKeeper set to auto-upload new QSOs to one or more online-logbooks? If so, that is a likely cause of the occasional extended logging times. That has been experience by JTAlert/DXKeeper users in the past.

Regarding a "Retry" button, that would seem to be the most sensible if it wasn't' for the code I have to work with. All the logging code is in the main JTAlert executable and runs on the UI thread. A Retry will involve a database access and a timeout value (if the lookup was unsuccessful), both of which will block the main thread. I am hesitant to add further blocking code. I will give it some thought.

de Laurie VK3AMA

Hi Laurie,

thanks for that, the online lookups are most probably the issue as I have a WiFi connection in the shack which is a bit QRP. No problem on the issues with implementing a "Retry" button, I had assumed that as the failure message doesn't time out that the required code to retry the logbook lookup was easily accessible, but if that is not the case I fully understand the issues. Since no one else has chipped in with similar requests, I am fine with just clearing the B4 cache when this happens. Normally it is pretty obvious where a station is running a frequency and continues to call after a QSO, I have to be pretty distracted not to notice that I have just worked them.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


Dev Null
 

Upgraded to 12 GB. CPU still at 100% but memory better.
I am sorry,  I can't help it, but misinformation in public forums really bothers me. Especially in a great group like this one.

(This is not directed at you personally, I am just using your post as an example.) It is unfortunately true that folks in general think that increasing RAM will make computers faster. In 90% of cases, it will make no difference whatsoever. The only time it does is when the computer is actually deficient, which never happens any more, since all have come with at least 8GB for many years now.

This is not to say that I personally don't load them up with RAM too. But it is only for "insurance."

I take care of hundreds of Windows machines, been doing it for decades, and I regularly check their actual RAM usage. You can do this yourself by just hitting ctl-alt-del and looking at task manager. You will find that in most cases, even with multiple programs running, usage will be below 4GB. The reason people add RAM is simple: because they can. 

I commend you for pointing out the single biggest improvement anyone can make to a computer today, which is to switch from a mechanical hard disk to a SSD (solid state drive.) Doing this will give you more improvement by far than anything else you can do, short of replacing the computer. It is truly dramatic.

As you mentioned, the street price of a 256 SSD is down below $50 US, so this is a no-brainer. Finally, I would suggest a clean install to the new SSD, rather than a clone, but I do understand that many are not up to that. In the words of Adrian Monk, "you will thank me later."


David De Coons
 

It is not misinformation about the RAM. I did not know at the time his CPU was at 100%. He had 4 GB ram running Windows 10 with SmartSDR (for Flex Radio), SSDR CAT, SSDR DAX, JTALERT, WSJT-C, HRD and HRD Logbook running. As I stated his ram usage was over 70%. The poor laptop was swapping stuff back and forth to the swap file on the hard drive. RAM upgrade was the easiest thing to try first. Again 4 GB is NOT enough. 

The video adapter was the cause of CPU @ 100%. Once he changed the cable and used the native display port VPU came down to a very reasonable level. 

I too have been working with PCs since the 8086 days. 

73
Dave wo2x

Sent from my waxed string and tin cans. 

On May 12, 2020, at 9:10 AM, Dev Null <aptget@...> wrote:


Upgraded to 12 GB. CPU still at 100% but memory better.
I am sorry,  I can't help it, but misinformation in public forums really bothers me. Especially in a great group like this one.

(This is not directed at you personally, I am just using your post as an example.) It is unfortunately true that folks in general think that increasing RAM will make computers faster. In 90% of cases, it will make no difference whatsoever. The only time it does is when the computer is actually deficient, which never happens any more, since all have come with at least 8GB for many years now.

This is not to say that I personally don't load them up with RAM too. But it is only for "insurance."

I take care of hundreds of Windows machines, been doing it for decades, and I regularly check their actual RAM usage. You can do this yourself by just hitting ctl-alt-del and looking at task manager. You will find that in most cases, even with multiple programs running, usage will be below 4GB. The reason people add RAM is simple: because they can. 

I commend you for pointing out the single biggest improvement anyone can make to a computer today, which is to switch from a mechanical hard disk to a SSD (solid state drive.) Doing this will give you more improvement by far than anything else you can do, short of replacing the computer. It is truly dramatic.

As you mentioned, the street price of a 256 SSD is down below $50 US, so this is a no-brainer. Finally, I would suggest a clean install to the new SSD, rather than a clone, but I do understand that many are not up to that. In the words of Adrian Monk, "you will thank me later."


g4wjs
 

Dave,

did you read my OP? here's a quote of it:

"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."

Note that the problem is not a failure to log QSOs, but a failure by JTAlert to check that the QSO was logged successfully. I'm sure you reply may be of use to others but it does not address the issue being discussed in this thread.

73
Bill
G4WJS.

On 12/05/2020 13:48, David De Coons wrote:
Here’s something to check.
Myfriend was having intermittent issues using a Lenovo i5 laptop. We found his CPU running @ 100% and memory around 70%. A little digging found he had two hardware issues.

1) he was running Win 10 woth only 4 GB ram. Upgraded to 12 GB. CPU still at 100% but memory better.

2) he was using a USB to HDMI adapter plugged into a USB 2.0 port for an external 36” TV as a monitor. This was the bottleneck. The laptop has a mini display port so he replaced the adapter with a mini display port to HDMI cable. CPU now around 30% and memory around 30%.

Last, yesterday he cloned the laptop drive to a solid state drive (they are cheap now here in U.S.). He put the SDD drive in the laptop in place of the original drive. Now everything is running MUCH faster.

For HRD Logbook we converted his log from Access to SQL Lite using MariaDB. With larger logs (mine has 20,000 contacts) it speeds logbook database queries up.

And last comment. For the reply on failed to log QSOs you can click on log QSO in WSJT-X as long as you haven’t started the next QSO. Just remember to check the start time.

Some of the intermittent logging issues may be due to CPU or memory bottlenecks in the PC. Not saying al are due to this but worth checking.

73
Dave wo2x


On May 12, 2020, at 6:37 AM, g4wjs <bill.8@...> wrote:


On 12/05/2020 07:22, HamApps Support (VK3AMA) wrote:
On 11/05/2020 9:37 pm, g4wjs wrote:

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

Bill,

Do you have DXKeeper set to auto-upload new QSOs to one or more online-logbooks? If so, that is a likely cause of the occasional extended logging times. That has been experience by JTAlert/DXKeeper users in the past.

Regarding a "Retry" button, that would seem to be the most sensible if it wasn't' for the code I have to work with. All the logging code is in the main JTAlert executable and runs on the UI thread. A Retry will involve a database access and a timeout value (if the lookup was unsuccessful), both of which will block the main thread. I am hesitant to add further blocking code. I will give it some thought.

de Laurie VK3AMA

Hi Laurie,

thanks for that, the online lookups are most probably the issue as I have a WiFi connection in the shack which is a bit QRP. No problem on the issues with implementing a "Retry" button, I had assumed that as the failure message doesn't time out that the required code to retry the logbook lookup was easily accessible, but if that is not the case I fully understand the issues. Since no one else has chipped in with similar requests, I am fine with just clearing the B4 cache when this happens. Normally it is pretty obvious where a station is running a frequency and continues to call after a QSO, I have to be pretty distracted not to notice that I have just worked them.

73
Bill
G4WJS.



--
73
Bill
G4WJS.


David De Coons
 

Hi Bill

My bad. I thought it was intermittently not logging. 

My friend with the laptop was having intermittent issues logging from JTALERT to HTD Logbook. In his case it was due to the laptop resources being maxed out. With the upgrades I mentioned he is running fine and he has not complained pf no or intermittent logging since. 

I apologize if the recommendations were off course. 

73
Dave wo2x

Sent from my waxed string and tin cans. 

On May 12, 2020, at 2:01 PM, g4wjs <bill.8@...> wrote:


Dave,

did you read my OP? here's a quote of it:

"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."

Note that the problem is not a failure to log QSOs, but a failure by JTAlert to check that the QSO was logged successfully. I'm sure you reply may be of use to others but it does not address the issue being discussed in this thread.

73
Bill
G4WJS.

On 12/05/2020 13:48, David De Coons wrote:
Here’s something to check.
Myfriend was having intermittent issues using a Lenovo i5 laptop. We found his CPU running @ 100% and memory around 70%. A little digging found he had two hardware issues.

1) he was running Win 10 woth only 4 GB ram. Upgraded to 12 GB. CPU still at 100% but memory better.

2) he was using a USB to HDMI adapter plugged into a USB 2.0 port for an external 36” TV as a monitor. This was the bottleneck. The laptop has a mini display port so he replaced the adapter with a mini display port to HDMI cable. CPU now around 30% and memory around 30%.

Last, yesterday he cloned the laptop drive to a solid state drive (they are cheap now here in U.S.). He put the SDD drive in the laptop in place of the original drive. Now everything is running MUCH faster.

For HRD Logbook we converted his log from Access to SQL Lite using MariaDB. With larger logs (mine has 20,000 contacts) it speeds logbook database queries up.

And last comment. For the reply on failed to log QSOs you can click on log QSO in WSJT-X as long as you haven’t started the next QSO. Just remember to check the start time.

Some of the intermittent logging issues may be due to CPU or memory bottlenecks in the PC. Not saying al are due to this but worth checking.

73
Dave wo2x


On May 12, 2020, at 6:37 AM, g4wjs <bill.8@...> wrote:


On 12/05/2020 07:22, HamApps Support (VK3AMA) wrote:
On 11/05/2020 9:37 pm, g4wjs wrote:

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

Bill,

Do you have DXKeeper set to auto-upload new QSOs to one or more online-logbooks? If so, that is a likely cause of the occasional extended logging times. That has been experience by JTAlert/DXKeeper users in the past.

Regarding a "Retry" button, that would seem to be the most sensible if it wasn't' for the code I have to work with. All the logging code is in the main JTAlert executable and runs on the UI thread. A Retry will involve a database access and a timeout value (if the lookup was unsuccessful), both of which will block the main thread. I am hesitant to add further blocking code. I will give it some thought.

de Laurie VK3AMA

Hi Laurie,

thanks for that, the online lookups are most probably the issue as I have a WiFi connection in the shack which is a bit QRP. No problem on the issues with implementing a "Retry" button, I had assumed that as the failure message doesn't time out that the required code to retry the logbook lookup was easily accessible, but if that is not the case I fully understand the issues. Since no one else has chipped in with similar requests, I am fine with just clearing the B4 cache when this happens. Normally it is pretty obvious where a station is running a frequency and continues to call after a QSO, I have to be pretty distracted not to notice that I have just worked them.

73
Bill
G4WJS.



--
73
Bill
G4WJS.