Hello,
I have successfully setup LoTW and uploading logs to LoTW works correctly. However, when I try to download my confirmations from LoTW into CQRLOG, it awill not mark LoTW confirmation as confirmed.
The log shows that 60 confirmations were downloaded from LoTW correctly with no errors.
In a previous attempt, it marked 1 QSO as confirmed by LoTW in CQRLOG. That one QSO remains confirmed in CQRLOG, but in spite of repeated attempts, the other 60 will not import.
Any Ideas?
Here is the log:
Size: 21681
Connected to LoTW server
File downloaded successfuly
File:
/home/user1/.config/cqrlog/lotw/2014-09-11_16-27-26.adi
Preparing import ....
Import complete ...
New QSOs confirmed by LoTW:
2014-09-08 VE7WJ 12M SSB
2014-08-28 W1AW/7 20M SSB
2014-04-09 W1AW/KP4 15M SSB
2014-04-11 W1AW/KP4 12M SSB
2014-04-12 W1AW/4 40M SSB
2014-04-12 W1AW/1 20M SSB
2014-04-23 VE2CSI 20M SSB
2014-04-27 YY1YLY 10M SSB
2014-04-28 W1AW/1 15M SSB
2014-04-28 PY2NZ 15M SSB
2014-05-12 W1AW/0 10M SSB
2014-05-29 UT7UU 20M SSB
2014-05-29 UR5GDX 20M SSB
2014-05-17 P40A 10M SSB
2014-05-17 KP4RV 10M SSB
2014-05-17 DF9ZP 15M SSB
2014-06-01 W1AW/0 12M SSB
2014-06-01 W1AW/0 10M SSB
2014-06-07 OM2VL 15M SSB
2014-06-07 OM2VL 15M SSB
2014-06-09 OD5ZZ 20M SSB
2014-06-18 AM07JZ 15M SSB
2014-06-23 W1AW/KL7 15M SSB
2014-06-25 SV9CVY 20M SSB
2014-06-26 OK1CF 20M SSB
2014-06-26 W1AW/3 15M SSB
2014-06-26 RU3FM 20M SSB
2014-06-26 W1AW/3 20M SSB
2014-06-26 W1AW/3 12M SSB
2014-07-02 K2C 20M SSB
2014-06-27 HA4XH 15M SSB
2014-07-04 UA3KW 20M SSB
2014-07-04 OK1CF 20M SSB
2014-07-04 K2L 20M SSB
2014-07-04 K2K 20M SSB
2014-07-04 K2H 20M SSB
2014-07-04 K2E 20M SSB
2014-07-12 YO3CZW 20M SSB
2014-07-06 WM3PEN 20M SSB
2014-07-05 W3FT 20M SSB
2014-07-10 V47JA 20M SSB
2014-07-12 FG8OJ 10M SSB
2014-07-12 R7DX 20M SSB
2014-08-06 VP5/K9HZ 20M SSB
2014-08-16 W1UJ 20M SSB
2014-08-09 W1AW/1 20M SSB
2014-08-16 K6MM 15M SSB
2014-08-16 K6GT 15M SSB
2014-08-16 K1RM 20M SSB
2014-08-16 WB9KPT 20M SSB
2014-08-22 UA9MA 20M SSB
2014-08-22 OM3LK 15M SSB
2014-08-25 NH6Y 15M SSB
2014-08-25 KH6LC 15M SSB
2014-08-22 F6GCP 17M SSB
2014-08-27 YV4NN 17M SSB
2014-08-27 SK6AW 20M SSB
2014-09-01 HK1T 10M SSB
2014-08-26 CT3MD 12M SSB
2014-08-27 8P6NW 17M SSB
-----------------------------
Total: 60 new QSOs
Thu, 2014-09-11 22:38
#1
LoTW Confirmations Not Importing
Hi,
very interesting, I also use LoTW but I've never had this problem. Could you run cqrlog from console with --debug=1, please? There should be more info and maybe there will be why QSO are not marked as CFM. Thank you!
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Thanks for the reply.
I have done as you suggested, but the logging is quite verbose.
The debug log is too big to copy and paste here.
I did notice a couple of things.
1) The only QSO being marked as confirmed is the last one being sent according to the debug logging.
2) There are 2 errors displayed after the data has been received - they are:
(cqrlog:2359): GLib-CRITICAL **: Source ID 3508 was not found when attempting to remove it
(cqrlog:2359): GLib-CRITICAL **: Source ID 3704 was not found when attempting to remove it
73
Here is the first part of the debug log once inporting begins:
DBPing - select * from cqrlog001.db_version
DLLSSLName:/usr/lib/i386-linux-gnu/libssl.so
DLLUtilName:/usr/lib/i386-linux-gnu/libcrypto.so
SSLLibFile:
SSLUtilFile:
https://LoTW.arrl.org/lotwuser/lotwreport.adi?login=ku4gu&password=xxxxx..."yes"&qso_qslsince=2000-01-01&qso_owncall=KU4GU
LoTW.arrl.org:443
LoTW.arrl.org:443
IPv4
LoTW.arrl.org:443
220
245
6
4096
2
6
4096
2
6
4096
2
6
4096
2
6
4096
2
5
904
2
5
SSLLibfile:
Call: VE7WJ
Band: 12M
Mode: SSB
QSO_date: 20140908
Time_on: 200300
QSLR: Y
QSLRDate: 20140911
CQZ: 3
ITUZ: 2
IOTA:
Grid:
State: BC
County:
------------------------------------------------
select time_on,lotw_qslr,waz,itu,iota,loc,state,county,id_cqrlog_main from cqrlog_main where (qsodate ='2014-09-08') and (band = '12M')and (callsign = 'VE7WJ')
select time_on,lotw_qslr,waz,itu,iota,loc,state,county,id_cqrlog_main from cqrlog_main where (qsodate ='2014-09-08') and (band = '12M')and (callsign = 'VE7WJ')
VE7WJ|20:03:00 | 19:58:00|20:08:00
update cqrlog_main set lotw_qslr = 'L'
,lotw_qslrdate = '2014-09-11'
,waz = '3'
,itu = '2'
where id_cqrlog_main = 128
qsl number:1
The mysql-db commands seems to be generated but not to be executed. As a workaround you could copypaste the update-statements from debug to the mysql console in cqrlog (Filter -> QSL console).
Example from kug4u's debug output:
update cqrlog_main set lotw_qslr = 'L' ,lotw_qslrdate = '2014-09-11' ,waz = '3' ,itu = '2' where id_cqrlog_main = 128 qsl number:1
would be one of this commands (for one QSO) to manually execute in cqrlog (or any other mysql-prompt)
same issue and workaround with eqsl.
73, Bernd DL8BH
a simple webinterface for cqrlog, screenshots over here: http://www.dl8bh.de/cqrweblog/
Hi!
Just saw the same here (version 1.8.1). It worked correctly the last time I imported from LoTW (a week ago), but today it refuses to mark the downloaded LoTW confirmation as confirmed in the log and statistics. I've had problems with computer crashes that sometimes has put some disorder in the data base. But this time I dont belive it has crashed.
/Mikael SM6VJA
Mikael SM6VJA
I just remembered that I recently had a an update of MariaDB pushed down to me through Update Manager. I wonder if this has anything to do with it breaking?
SM6VJA - Did you install the update? Do you remember if that is when it stopped working?
Yes, I recall seeing something like MariaDB while updating, so probably my computer swallowed that one.
I dont know exactly when the LoTW problem started because 14.04 is new to me and I just got it running without a crash every 20 minutes (graphics driver issue), so I have just started to use it more regularly. So, I'm in the process of "moving in" to this machine. But I'm pretty sure, 1.8.1 did import Lotw confirmations when I started using it.
I also tried the debug-mode as suggested but it was a huge list and only a fraction could be explored in the terminal window. Can the whole content be exported to a file instead?
I'm not too good on Linux command line stuff...
The I created a new log with only one QSO in it and then tried to download the Lotw QSO confirmation, but it just would not import it. My hope was that the debug list would be shorter, but it certainly was not...
If I can help, tell me what I can do.
BR Mikael SM6VJA
Mikael SM6VJA
KU4GU:
As I understand the MariaDB is very closely related to MySQL. Could it be that it messes up something that is shared by both Maria ans My SQL? May be one should try to uninstall both MariaDB, My SQL and all that is related to CQRLOG and start from scratch?
Petr: -Have you got the MariaDB installed?
/Mikael SM6VJA
Mikael SM6VJA
I learned a lot about MariaDB over this weekend (don't ask how, ugh!), and basically it is a mysql replacement. I, too, received the update. However, I was still seeing this issue before the update, so I'm not certain that MariaDB has much to do with the issue.
For what it's worth, I also use eQSL and I see similar problems with it as well, but on the upload side. It seems like QSOs that have already been uploaded are not being marked as such, and so they are uploaded again each time.
Now, this is where it gets interesting. Just for giggles, I ran CQRlog in debug mode and captured the output to a file. I then looked for the 'update' statements the program used to update the QSL received info for the 2 LOTW qsos that were showing this problem (same ones showing as "newly confirmed" each time I download). They looked right-ish, so I opened up a mysql shell to the main database to view the records by hand. So far so good.
Now, I copy-pasted the 'update' SQL query from the debug log into my command prompt and ran it on the database by hand. It updated the records just fine, and now my LOTW download shows 0 newly confirmed QSOs. One thing I did was run a 'commit;' command after the 'update' in the prompt. I don't know if that's necessary or not, though.
So, it appears that either the update command is not being executed at all during the download, or that a 'commit' that may need to be done is being skipped after the records are updated. What I have managed to rule out is that the database is somehow buggy and not able to update the records - if the application (in my case, the command prompt) tells mariaDB to do the right thing, then it works and CQRlog is happy.
Great! You are getting close to the root-cause. I threw out MariaDB, threw out CQRLOG, threw in MySQL and again CQRLOG (which seemed not to erase totally because it started configured as before...). With MySQL running instead of MariaDB there was no difference. Still same problem. So I'm ready to accept that MariaDB may not be the problem.
I wonder if we are the only few ones with this problem, or if it is to be discovered by more users.Petr himself does not seem to have this problem.
73 / Mikael SM6VJA
Mikael SM6VJA
I guess my next step is to fetch the source, build it, and play around. Unless Petr or someone steps in with a better idea.
Wish me luck!
73, Bill WK2X
Import is ok, but marking of new confirmation does not work. List of confirmations given is ok, but there is no mark in the log so redoing the lotw import lists the same stations.
Hope that this will be fixed soon. Have tried to start in debug mode, but debug level 1 did not give me any meaning ful info.
73 de Olaf - LA3RK
Olaf Devik LA3RK
I can confirm the eQSL issue reported by WK2X above as well. QSOs that have already been reported are being resent although I selected to only send new QSOs.
Something I don't know if its accidental:
this problem just happens with my amd64 machine but not with my i386 laptop. Same external mysql-server for both…
a simple webinterface for cqrlog, screenshots over here: http://www.dl8bh.de/cqrweblog/
DL8BH, that is GREAT information. I, too, am running an amd64 machine - I wonder if there's some sort of integer exception happening that the program isn't handling? I also wonder if the program can be built in 32-bit mode, in spite of the host architecture and that may fix things? I will have to see. Thanks for posting, though, it gives me some good ideas of where to look.
Yesterday, I grabbed the latest source code from Petr's github and built it on my machine - this version would be newer than 1.8.1, and not official. But, I also noticed that my preferences weren't being saved, like my LOTW login credentials and stuff. It seems like most, maybe all database update operations are failing. New QSOs can still be logged, though, because they are INSERT operations, not UPDATE.
When/if I have time, I will try to set up a "test" log to play with so I don't screw up my actual log / preferences. I've reverted my machine back to version 1.7.1 for now, but I think I might be able to use 1.7.1 for my actual log and 1.8.x with my test log, hopefully with no ill effects. If I can get that environment going, then I can start tracking stuff down, maybe. Of course, I'm open to suggestions as to how to accomplish this.
This should be fun - I've never programmed in Pascal before ;)
I'm not sure the processor has anything to do with it. I'm using a 32 bit Intel processor...
I have the same problem, only one of 60 qso:s are listed as confirmed in Cqrlog.
My setup are:
Intel® Core™2 Duo CPU P8600 @ 2.40GHz × 2
Ubuntu 14.04 64bit
Cqrlog 1.8.1
Mysql
I have just started using LoTW and this problem showed up away.
Robert
Hi,
I created a build of cqrlog (64bit) for testing. It can be downloaded from http://cqrlog.com/files/cqrlog_lotw.tar.gz
It's complete application directory with all files.
Changelog is here: https://github.com/ok2cqr/cqrlog/blob/master/src/CHANGELOG
I made a few changes to the code handling transactions around eQSL and LoTW import. I'd like to ask you for help with testing. Bug with LoTW import doesn't affect my database. I do a lot of testing new features or test new ideas on my DB and it's possible I made some changes that I didn't write back to the update db code.
If you want to run this testing build, please follow these steps.
1) backup of ~/.config/cqrlog directory
2) untar the archive and copy cqrlog directory to your home folder
3) open terminal, switch to ~/cqrlog/usr/bin directory
4) run cqrlog with this command ./cqrlog --debug=1 >> debug.txt
5) download the data from LoTW/eQSL
6) close the cqrlog
Now please send me debug.txt file to my email and let me know if it helped or not. Thank you!
Why the backup of ~/.config/cqrlog? This build is only for testing and I could forget to something. It's always good to have a way to return to working configuration.
Thank you for your help!
73 Petr
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Thanks Petr, it works for me.
The output from debug is in your mail.
73's Robert
For info, error is present here as earlier reported. My system reports being a 32 bit system and the special 64 bit edition will therefore not run. Seems the error also is present on 32 bits system. If necessary, a debug.txt file can be prepared and sent those interested.
I appreciate Petr hard work that has gone into CQRLOG and being 100% linux in my station pc, CQRLOG is a must for me and much appreciated. I can live with the missing import for the time being.
Happy DX hunting and 73 de Olaf - LA3RK
Olaf Devik LA3RK
Hi Petr,
I can confirm that the new released version 1.8.2 has fixed this problem. It also feels a lot faster in general.
Very good work! Sorry I didn't have much time to help out.
73,
Bill WK2X