JTAlert logging failure

[w9mdb]

A number of us using JTAlert with Log4OM have been experiencing logging failures lately.
Laurie tried a patch that reopened the UDP port thinking there might be some bug in the autoit software he uses for JTAlert. But it appears that doesn't solve the problem. The symptom is that the UDP packet doesn't show up on the network capture (I've been testing this after experiencing probably a dozen failures). The problem doesn't happen very often and a 2nd attempt usually works....so hard to debug. Could be JTAlert, could be Windows 10 fault....apparently not Log4OM's fault since network packets never shows up on capture.

Log4OM is the only logger using UDP instead of TCP for logging. Could a TCP port also be added to Log4OM please so this problem can be solved with a more reliable protocol? I wouldn't replace the UDP capability...just add a 2nd port using a TCP socket. I am 100% sure a TCP socket would solve this problem as the people using other loggers are not experiencing this....just Log4OM users.

de Mike W9MDB

[DF5WW]

Hi Mike,

from time to time i have the same problem here but not on each error message the qso will be not logged. Most time when JT-Alert gives this error message the qso is logged but the response from the database needs to much time. On my side it´s a result of a slow internet connection. JT-Alert loggs the contact to my sqlite database and Log4OM starts upload to eQSL, HamQTH and Clublog. In this time JT-Alert does not receive an information the contact is logged or not.

This helps for this kind of error:

Open the settings in JT-Alert and open the option "Miscellaneus" on the left side. Go to performance and change the entry "Check QSO Log Record" to a higher level.

Other problem here is that the communicator from time to time lost the TCP connection to Log4OM. If that occures the qso will be not logged in Log4OM. My option is to leave the communicator window open if i use WSJT-X/JT-Alert-X so i can see the communicator is connected or not. You don´t need to start and stop the coommunicator. If the "light" shows red for the TCP connection a simple hit on the button right of the entry is all you need (before you hit the Log QSO button in WSJT-X) and the contact will be logged.

df5ww_1.png (47.13 KiB) Viewed 7973 times

Hope that will be help you for a while. As you know, Log4OM V1 is only in maintenance mode. So code changes will be only made in V2 and that needs time.

[w9mdb]

I increased the wait time in JTAlert a long time ago.
Never had a problem with communicator.
Was able to debug this problem and it is on JTAlert's side....but for some reason it just started happening the last few weeks and we don't know why. I'm working with Laurie to try and trace it down and on a 2nd "fix" attempt. Only happens every few days or so.
The behavior is JTAlert thinks it sent the UDP packet...but Log4OM real time log shows it wasn't received...and a network packet capture shows it wasn't really sent by JTAlert. Then you send a 2nd log attempt from WSJT-X and you get two UDP packets sent...then 2nd one of that group gets rejected by Log4OM as a duplicate.

Thing is....only Log4OM users are seeing this problem as all other loggers use a TCP connection.....ergo my reason for asking.

One other possible fix would be for Log4OM to provide an "ack" of the logging request....and maybe "ack duplicate"...or "ack failure [reason].....". That would go a long way towards allowing JTAlert to see if the request was received.

de Mike W9MDB

[WS2K]

Has anything further been discovered on this? I ask because this afternoon, unexpectedly, my LOG4OM stopped taking logging requests from JTAlert. The symptoms are exactly as stated. The program hangs, a failure notice comes in, and I can'topen LOG4OM for10 seconds or more. Finally, I can then reopen the screen and the QSO is there. This had always been a quick, smooth oeration with an almost immediate acknowledgement that the QSO was logged. Anything to watch out for? I didn't change anything betweein it working and not working. Thanks. De WS2K

[WB5UDI]

Same thing happened to me yesterday (Sept. 4, 2017) as well.....JTAlert logging problem was bypassed by telling it to stop posting the 'pop up' for logging failure, even though it works fine...and FAST...to Log4OM.......but yesterday, it started acting sluggish and finally one QSO didn't log. Communicator was working....but everything was MUCH SLOWER ........In trying to get the missed contacts into Log4OM, I did an ADIF IMPORT from the WSJT-X ADIF file......and now I have lots of DUPLICATES in my Log4OM database........how do I get rid of them easily?

[G4POP]

The symptoms are exactly as stated. The program hangs, a failure notice comes in, and I can't open LOG4OM for10 seconds or more.

Are you saying that Log4OM is not started and if you are have you tried with Log4OM already running?

This had always been a quick, smooth operation with an almost immediate acknowledgement that the QSO was logged. Anything to watch out for? I didn't change anything between it working and not working.

Something has to have changed on your computer like a Windows or Virus software update?

[G4POP]

yesterday, it started acting sluggish and finally one QSO didn't log. Communicator was working....but everything was MUCH SLOWER

Again it has to be something like an update to Windows or some other software (Even JTAlert or WSJT-X) causing the slow up, for example recently I had a slowing down of everything which I finally discovered was due to 'MalwareBytes' choosing to do a massive scan at a regular time each day, unfortunately the time was in the middle of my normal operating hours!

In trying to get the missed contacts into Log4OM, I did an ADIF IMPORT from the WSJT-X ADIF file......and now I have lots of DUPLICATES in my Log4OM database

Log4OM will not accept EXACT duplicates therefore there must be some difference to the data between what was logged via JTAlert and that in the WSJT-X ADIF file. Most likely frequency, mode or time!

how do I get rid of them easily?

Identify what the difference in the data was then filter by that field in the QSO Manager and delete the dupes

[G4POP]

Gentlemen,

Please bear in mind that you have two other external programs involved in this issue and that it is more likely to be one of them causing the issue than Log4OM.

I say this because basically Log4OM just sits there, patiently waiting for incoming data to be written directly to the Log4OM database!

It might be appropriate to ask the questions of the other two software providers?

[WS2K]

Terry - I don't think anything changed with LOG4OM. It is likely an update to Windows that broke the system (since my current JTAlert and WSJT-X used to work with my current LOG4OM). But since the only program being affected is LOG4OM, I thought I'd search here first to see if anyone found out what is keeping LOG4OM from doing its normal excellent process. It was interesting to see that I am not the only one with this issue suddenly happening yesterday. If I discover any causes I'll post them. Thanks.
73...Joe

[WS2K]

I might have found something. I went to update several QSOs in the log that were missing names and other info. I had LOG4OM set to use HAMQTH to fill in the missing info. When I opened up the QSO and hit "Update", it stayed locked/spinning for about 10 seconds before coming up empty. This replicated the timing hangup I saw in the logging process! I changed the reference to QRZ.com, and all is working speedily and normally again. So it MIGHT be a problem with HAMQTH locking up while getting the data. But for now, this was the only change I made, and all is well again. I hope it is corrected, as LOG4OM is one of the best programs I have used anywhere. If I learn anything else I'll post. 73 Joe