Hi, all
I made a contact with D2UY this morning, and I noticed that the country name shown on the country column was Thailand.
On the contrary, in DXCC info, it is shown as Angola.
It would be grateful if you let me know how to fix this.
CQRLOG version: 2.6.0(001)Gtk2
XUBUNTU 22.04
Hi!
Martin OK1RR does the DXCC/QSLmgr update. He has already released update, quick as always.
In my Cqrlog that loaded new DXCC/QSLmgr info on this morning start D2UY shows up as Angola.
--
Saku
OH1KH
Hi Saku,
Thank you very much for your reply.
It seems that I have to wait until new DXCC/QSLmgr info update.
So far, nothing has changed in my CQRLOG.
JA6LJN
KAZ
Hi Kaz!
Be sure that you have these checked
--
Saku
OH1KH
I have the same corrupted country issue with CQRLOG 2.5.2 on Linux Mint.
The other day, I worked CO2XN on SSB and when I entered his information via the UI, the country said Cuba.
Some time later (I think right after I had selected Rebuild DXCC statistics), CO2XN showed up as Guadaloupe Island. I was not able to correct it from within CQRLOG by editing, so I deleted the QSO and re-entered it manually as a new QSO (Deleting the previous one) and it showed to be correct.
I then imported more QSO's from a wsjtx snippet.
Now CO2XN shows up as being in the United States, and a subsequent QSO with N1NAZ (Literally across town from me, and coincidentally my most recent qso) shows that HE now is in Guadaloupe Island...
I had a similar issue with CY0S (And other folks previously) and ended up deleting his entry and making a 1 line ADI to re-import.
In both cases, this seemed to happen to the qso that was most recent (I.e. at the top of the log). Also, in temrs of a potential pattern, CO2XN is corrupted by the country of my most recent import N1NAZ and my most recent import says Guadaloupe Island.
Several months ago, CQRLOG stopped asking me if I wanted to ignore duplicates when Import logs, and started duplicating everything, so I have just been uploading manually de-duped log snippets (trimmed from a wsjtx_log.adi), which I have visually confirmed to be correct. My QSO with CO2XN was on SSB, so I can confirm that this happens for entries that are both imported, and added directly from the CQRLOG UI.
A year or so ago, I had uploaded my logs to hrdlog, and their dxcc check had flagged several similar situations from the past, so this is not a new behavior (And I have already been through one cycle of export everything and re-import into a new database.)
Is there a fix for this? (or conversely, can I do anything to help supply debug info?)
I love CQRLOG, but really can't have stuff getting corrupted in the background like this.
--al
WB1BQE
File:
HI Al!
So much has happened since 2.5.2 was released!
And unfortunately the latest official 2.60(001) is not released as package.
How ever there is an update script in my GitHub that allows you to upgrade your Cqrlog to official 2.6.0(001) or to my Alpha version 2.6.0(114) that is 229 commits ahead of official 2.6.0(001).
You find it from https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled
but one word of warning:
You did not state your Mint version. If it is as old as your Cqrlog it might be that you have old version of GLIBC and that prevents latest Cqrlog to run.
To check this, please read first lines of README.md from the web page to know how to test before making update.
--
Saku
OH1KH
I'm at Mint 20.3 and glibc 2.31 on a relatively clean system.
Thanks Saku!
I just looked - I'm running Mint 20.3 with Glibc 2.31 (not 2.34)
At the time I built it, that was the latest and greatest, but time has passed...:)
I just googled quickly, and lots of folks recommend against trying to update glibc in isolation, so I'll probably need to hold off on attempting to upgrade cqrlog until I have updated mint itself. (it just has wsjtx, vnc and cqrlog on it, so rebuilding from scratch isn't the end of the world.)
Thanks and 73!
--al