Hi there,
I have an issue here on my 24/7 shack machine with mariadb & CQRLOG 2.4.0 & Ubuntu 20.04 LTS:
After some hours of no activity, when I click some action that triggers a db-request I get:
TMySQL57Connection : Error executing query: MySQL server has gone away.
Press OK to ignore and risk data corruption.
Press Abort to kill the program.
If I abort and restart everything's fine. The dbserver does not need any action from my side.
I'll try to log the whole thing tomorrow. - On my Laptop I had no problem during my OZ-Holiday when leaving CQRLOG open and putting the machine into standby (not hibernation) - CQRLOG was open many days without problems ... on similar hardware, install & config.
I'll post more details after a debug ...
73 and thanks
Stefan.
I have seen this too! I have seen this after using CQRLOG during the evening, leaving it running overnight, then the message appears the next day when I return to use it. I did not notice this during extended actual use (for example duration of Field Day). The idle (no activity) seems to be an important factor.
However, my configuration is a bit different - I use a separate MariaDB (virtual) server, over my LAN. I had not started to look closely at this, because there are a lot of parts involved - virtual-machine with KVM/QEMU, network-switches, SFP+ fiber-modules, workstation (idle) settings, TCP/IP settings everywhere... :-O
But now that you've identified this also, Stefan, I'll add my experience to this also!
CQRLOG version 2.3.0 compiled from (repository) source, on Gentoo
MariaDB version 10.3.23 installed via apt, on Debian
-Gord VA7GP
Hi Gord and Stefan!
Gord, I assume a typo in version number 2.3.0. Am I right?
If it really is 2.3.0 you can expect all kinds of troubles.
When leaving cqrlog running does it have any function in use that would use database?
DXCluster, RBNmonitor, wsjt-remote, or is it just "standing by" waiting for new qso input and perhaps polling radio that is also on?
From earlier years I remember that Petr has adjusted (or created. I cant remenber) a database poll to keep mysql happy.
It indeed can have property that it disconnects user if there is no activity.
But this can also happen by network router or firewall if those find out unused connection in their routing tables.
If there is no database usage open DXCluster, RBNmonitor or leave wsjt remote running with CQ monitor and wsjt-x.
Then there is database usage all the time and you can see if that affects.
--
Saku
OH1KH
Saku wrote:
Gord, I assume a typo in version number 2.3.0. Am I right?
Saku, I am embarrassed to admit that I was using the "official" Gentoo version - 2.3.0 - which is all that's available through the Gentoo package-management. But that is not helpful to me, you, nor Stefan... so, I have now installed your latest 6-day-old Alpha 2.4.0(122) version. I will let it run as much as I can - hopefully overnight once or twice this upcoming weekend.
Saku wrote:
When leaving cqrlog running does it have any function in use that would use database?
DXCluster, RBNmonitor
Yes, I left both RBN and DXCluster running the entire time. I am interested to see if your Alpha version 2.4.0(122) with on-going database activity will change things - kindly allow me several days to see...
Thank-you for your reminder about my old version, and helpful suggestions for nudging the database-server.
-Gord VA7GP
Hi Gord & Saku,
thanks for the information from your posts.
When I had the machine running in my holiday, I kept the DX-Cluster running. I switched that off yesterday for my overnight test, to have not so many debug messages ... and then both machines (the one in standby and the one running normally) hungup with the DB.
Here are the final lines from the log:
12
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
WARNING: TBitBtn.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event?
Deleting config file: cqrlog.cfg
Deleting config file: 2cqrlog.cfg
Closing dData
Closing ini file ...
Closing dData
Note: GetTextBuf is overridden for:
Access violation
Killed
(NB: I had to kill manually, as the "Abort" did not fully end CQRLOG).
But If I get Saku right, just switching the Cluster or RBN on should insure DB-activity and hence avoid this problem. So I tried again lst night with DX-Cluster (Web), as this will not log me out after some time.However, on the machine left on (no standby), CQRLOG crashed again, here the final debug messages:
Closing DXCluster windowClosing TRXControl window
Closing GrayLine window
Closing ini file ...
Closing dDXCC
[FORMS.PP] ExceptionOccurred
Invalid file handle
On the other machine (DX-Cluster via telnet & standby) CQRLOG survived the night.
... this is really odd.
73 & Thanks
Stefan.
73
Stefan.
--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE
Hi !
Just to check are you running alpha or official?
Is that error text really from crash, or does it come from trying to close stopped cqrlog?
I think that if cqrlog gets stuck it does not make "closing...." lines.
What I am after is that when cqrlog seems to be dead it is not (in the means that not all processes are dead, perhaps just ones that product screen update) and when you try to close it it still can do some closing operations but not up to final stage.
When you notice cqrlog is dead and you have debug messages on check what are the latest messages (without trying to close cqrlog) and does there appear any new debug lines after the main display(s) are not anymore updating.
--
Saku
OH1KH
I left CQRLOG running overnight, with RBN and HamQTH DXCluster running.
When I returned in the morning, I noticed that the BandMap is still updating, and the DXCluster is still running.
I then tried double-clicking on a BandMap entry - that's when I got the error
TMySQL57Connection : Error executing query: MySQL server has gone away.
Perhaps the attached screenshot will help. I did not start CQRLOG in a console, so I have no further debug information. I'll try console-launch later.
I was curious after receiving the MySQL error - I wanted to see "how much" of CQRLOG would continue to work. Using the TRX Control, I can change Modes, but I cannot change bands. Attempting to change bands also produces the MySQL error message.
For connection to my rig, I am using FLRig. I started FLRig in a console, and this displays no errors. FLRig continues to change rig frequency, mode, VFO, filter, etc. FLRig and also CQRLOG properly update the frequency when I manually tune.
I am running CQRLOG Alpha 2.4.0(122)
Thank-you, Saku,
-Gord VA7GP
File:
Thanks Gord!
First Google hit: https://matomo.org/faq/troubleshooting/faq_183/
Might be worth of trying that if cqrlog seems to be somehow still alive.
--
Saku
OH1KH
Hi Saku,
... this reads really interesting.
Just added the
wait_timeout = 28800to the [mysqld] section of my config.Looking forward, to what happens tomorrow ...
Thanks again & 73
Stefan.
--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE
Saku wrote:
Might be worth of trying that <...>
Good idea!
So, at my (remote/LAN) server, I find that the existing timeout is already what your article suggests:
MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'wait_timeout';+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout | 28800 |
+---------------+-------+
But the second suggestion may be useful, because my innodb_log_file_size is smaller:
MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'innodb_log_file_size';
+----------------------+----------+
| Variable_name | Value |
+----------------------+----------+
| innodb_log_file_size | 50331648 |
+----------------------+----------+
I added this line to my conf-file, re-started MariaDB and checked it:
innodb_log_file_size = 256MBMariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'innodb_log_file_size';
+----------------------+-----------+
| Variable_name | Value |
+----------------------+-----------+
| innodb_log_file_size | 268435456 |
+----------------------+-----------+
And the third suggestion - my max_allowed_packet is set at ~16MB:
MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'max_allowed_packet';+--------------------+----------+
| Variable_name | Value |
+--------------------+----------+
| max_allowed_packet | 16777216 |
+--------------------+----------+
So I added this line to my conf-file and checked it:
max_allowed_packet = 128MMariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'max_allowed_packet';
+--------------------+-----------+
| Variable_name | Value |
+--------------------+-----------+
| max_allowed_packet | 134217728 |
+--------------------+-----------+
Let me see what happens now...
-Gord VA7GP
Hi there,
I made another couple of tries.
No.1 - Laptop, all changes to mariadb config like described by Gord
When selecting QSO from QSO-list for "View" I got the message again, BUT CQRLOG closed clean when clicking "Abort".
Here's the log-tail from the end:
DX de F5EAN: 1296200.0 EA1UR IN96DKIN53TF 51 0928ZEnter critical section On Receive
Leave critical section On Receive
Found - EA1UR
SELECT * FROM cqrlog_common.bands where (b_begin <=1296.2 AND b_end >=1296.2) ORDER BY b_begin
SELECT * FROM cqrlog_common.bands where (b_begin <=1296.2 AND b_end >=1296.2) ORDER BY b_begin
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 AND band='23CM' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 AND band='23CM' AND mode='SSB' LIMIT 1
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 AND band='23CM' LIMIT 1
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 LIMIT 1
dx_prefix:EA
dx_cont: EU
Freq: 1296.2
Call: EA1UR
Color: clBlack
Index_: 2
Cannot show this sport because of settings ...
Found - NX4TT
SELECT * FROM view_cqrlog_main_by_qsodate WHERE idcall = 'NX4TT' ORDER BY qsodate,time_on
DX de F5RJK: 18156.0 YU3AWA 59+ 0927Z
Enter critical section On Receive
Leave critical section On Receive
Found - YU3AWA
SELECT * FROM cqrlog_common.bands where (b_begin <=18.156 AND b_end >=18.156) ORDER BY b_begin
SELECT * FROM cqrlog_common.bands where (b_begin <=18.156 AND b_end >=18.156) ORDER BY b_begin
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=296 AND band='17M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=296 AND band='17M' AND mode='SSB' LIMIT 1
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=296 AND band='17M' LIMIT 1
dx_prefix:YU
dx_cont: EU
Freq: 18.156
Call: YU3AWA
Color: clBlack
Index_: 3
Color for xplanet:0xFFFFFF
2020-08-09 11:28:57 add to bandmap YU3AWA
Color: clFuchsia
Index_: 3
TelThread.Execute - before Synchronize(@frmDXCluster.SynTelnet)
TelThread.Execute - after Synchronize(@frmDXCluster.SynTelnet)
Deleted data on position:0
select id_cqrlog_main from cqrlog_main where (callsign= 'YU3AWA') and (band = '17M') and (mode = 'SSB') and (str_to_date(concat(qsodate,' ',time_on), '%Y-%m-%d %H:%i')) > str_to_date('2020-08-07 11:28', '%Y-%m-%d %H:%i')
DX de SQ9GIN: 3700.0 SP5XTY/P GRJ-050 0929Z JO90
Enter critical section On Receive
Leave critical section On Receive
NOT found - T20DX
SELECT * FROM cqrlog_common.bands where (b_begin <=3.7 AND b_end >=3.7) ORDER BY b_begin
SELECT * FROM cqrlog_common.bands where (b_begin <=3.7 AND b_end >=3.7) ORDER BY b_begin
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=269 AND band='80M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
dx_prefix:SP
dx_cont: EU
Freq: 3.7
Call: SP5XTY/P
Color: clBlack
Index_: 0
Color for xplanet:0xFFFFFF
2020-08-09 11:29:00 add to bandmap SP5XTY/P
Color: clBlack
Index_: 0
TelThread.Execute - before Synchronize(@frmDXCluster.SynTelnet)
TelThread.Execute - after Synchronize(@frmDXCluster.SynTelnet)
Deleted data on position:0
select id_cqrlog_main from cqrlog_main where (callsign= 'SP5XTY/P') and (band = '80M') and (mode = 'SSB') and (str_to_date(concat(qsodate,' ',time_on), '%Y-%m-%d %H:%i')) > str_to_date('2020-08-07 11:29', '%Y-%m-%d %H:%i')
DX de EC5A: 7060.0 EA4CT CME 0929Z IM98
Enter critical section On Receive
Leave critical section On Receive
Found - EA4CT
SELECT * FROM cqrlog_common.bands where (b_begin <=7.06 AND b_end >=7.06) ORDER BY b_begin
SELECT * FROM cqrlog_common.bands where (b_begin <=7.06 AND b_end >=7.06) ORDER BY b_begin
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
dx_prefix:EA
dx_cont: EU
Freq: 7.06
Call: EA4CT
Color: clBlack
Index_: 0
Color for xplanet:0xFFFFFF
2020-08-09 11:29:05 add to bandmap EA4CT
Color: clBlack
Index_: 0
TelThread.Execute - before Synchronize(@frmDXCluster.SynTelnet)
TelThread.Execute - after Synchronize(@frmDXCluster.SynTelnet)
Deleted data on position:0
select id_cqrlog_main from cqrlog_main where (callsign= 'EA4CT') and (band = '40M') and (mode = 'SSB') and (str_to_date(concat(qsodate,' ',time_on), '%Y-%m-%d %H:%i')) > str_to_date('2020-08-07 11:29', '%Y-%m-%d %H:%i')
DX de SV1RRV: 18079.0 HA50KHW 50 Anniversary of Radio Sport 0929Z
Enter critical section On Receive
Leave critical section On Receive
Found - HA50KHW
SELECT * FROM cqrlog_common.bands where (b_begin <=18.079 AND b_end >=18.079) ORDER BY b_begin
SELECT * FROM cqrlog_common.bands where (b_begin <=18.079 AND b_end >=18.079) ORDER BY b_begin
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=239 AND band='17M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=239 AND band='17M' AND mode='CW' LIMIT 1
SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=239 AND band='17M' LIMIT 1
dx_prefix:HA
dx_cont: EU
Freq: 18.079
Call: HA50KHW
Color: clBlack
Index_: 3
1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
Deleting config file: 2cqrlog.cfg
Deleting config file: cqrlog.cfg
Closing dData
Closing ini file ...
Closing dData
[FORMS.PP] ExceptionOccurred
[FORMS.PP] ExceptionOccurred
But I cannot see anything enlightning in there ...
No.2 - Shack-PC, only timeout-changes made to mariadb config
When selecting QSO from QSO-list for "View" I got the message again, when clicking "Abort", CQRLOG hangs in the shutdown process. After a bit clicking around, I get a system dialog "CQRLOG does not answer. - Kill or wait?" then I clicked kill.
Here the log-tail:
Reconnected as DB4ST at 37.201.144.13, this instance is disconnected
SELECT * FROM profiles WHERE visible > 0 ORDER BY nr
1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing ini file ...
Closing dDXCC
[FORMS.PP] ExceptionOccurred
Invalid file handle
Getötet
The first line is the loss of the telnet-connection to the cluster.
The second line is the select of the qso, when cqrlog goes tits-up.
The [FORMS.PP] ExceptionOccurred seems to be the interesting message ...
Hope this helps.
73
Stefan.
--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE
Hi Saku,
I think my version is "official" - it comes with Ubuntu 20.04 and reads
2.4.0 (001) 2019-10-27I'll have another go with the debug info later.
The last 4 hours I set the shack PC to standby. - CQRLOG apparently survived this while being connected to the cluster with telnet (though the telnet-connection died on the way).
73
Stefan
--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE
I invoked CQRLOG with debug=1 but that didn't seem to provide helpful information :-(
On the other hand, my database server shows one helpful error, approaching 3am (perhaps after 7hrs of inactivity:
2020-08-09 2:56:14 41 [Warning] Aborted connection 41 to db: 'cqrlog001' user: 'cqrlog' host: '2001:470:1f05:be:5092:fd46:5a19:bded' (Got timeout rea
ding communication packets)
Although CQRLOG was running overnight, this is the only error.log entry from midnight (log-rollover) until 7am... (BTW - that IPv6 address is my ham-radio workstation, where CQRLOG / FLRig / etc are running. My DB server listens on all interfaces, and I don't specify anything more than server/port in CQRLOG. Somwhere, somehow my system "chooses" by itself to use IPv4 or IPv6... generally speaking, I prefer IPv6 for everything, because it's reachable from the world, with NAT/port-forwarding).
When I check the (non-error) log-file, I see "normal" entries like these, beginning at midnight (log rollover):
/usr/sbin/mysqld, Version: 10.3.23-MariaDB-0+deb10u1-log (Debian 10). started with:Tcp port: 3306 Unix socket: /run/mysqld/mysqld.sock
Time Id Command Argument
46 Query flush local slow logs
46 Quit
200809 0:00:37 42 Query ROLLBACK
42 Query START TRANSACTION
42 Query SELECT * FROM cqrlog_common.bands where (b_begin <=7.108 AND b_end >=7.108) ORDER BY b_begin
42 Query START TRANSACTION
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=281 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AN
D mode='SSB' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=281 AND band='40M' AND mode='SSB' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=281 AND band='40M' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=281 LIMIT 1
42 Query ROLLBACK
200809 0:00:45 42 Query ROLLBACK
42 Query START TRANSACTION
42 Query SELECT * FROM cqrlog_common.bands where (b_begin <=7.178 AND b_end >=7.178) ORDER BY b_begin
42 Query START TRANSACTION
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AN
D mode='SSB' LIMIT 1
<...>
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='10M' AND mode='CW' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='10M' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 LIMIT 1
42 Query ROLLBACK
200809 6:44:07 42 Query ROLLBACK
200809 6:44:08 42 Query START TRANSACTION
42 Query SELECT * FROM cqrlog_common.bands where (b_begin <=50.09 AND b_end >=50.09) ORDER BY b_begin
42 Query START TRANSACTION
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=236 AND band='6M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=236 AND band='6M' AND mode='CW' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=236 AND band='6M' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=236 LIMIT 1
42 Query ROLLBACK
200809 6:44:25 42 Query ROLLBACK
At this point, I'm puzzled...? It sort of looks, to me, like the database did experience an error, but that CQRLOG continued to transact with it, but only failed when I arrived and double-clicked a BandMap spot...?
-Gord VA7GP
The MariaDB server-log below shows the final active-entry (from me, working Rarotonga!) at 8:30pm. About 50min later is the last BandMap update...??? At 6:30am when I arrived back in the shack, the BandMap was completely empty, yet the cqrlog-log (debug=4) shows continuing DX Cluster spots.
200809 20:30:13 57 Query START TRANSACTION
57 Query select id_notes from notes where callsign = 'E51JD' limit 1
57 Query COMMIT
57 Query START TRANSACTION
57 Query insert into cqrlog_main (qsodate,time_on,time_off,callsign,freq,mode,rst_s,rst_r,name,qth,qsl_s,qsl_r,qsl_via,iota,pwr,itu,waz,loc,my_loc,county,award,remarks,adif,idcall,state,qso_dxcc,band,profile,cont,club_nr1,club_nr2,club_nr3,club_nr4,club_nr5, prop_mode, satellite, rxfreq, srx, stx,srx_string, stx_string, contestname, dok) values('2020-08-10','03:30','03:30','E51JD',14.225,'SSB','59','59','Jim','Rarotonga, South Cook Islands','','','','','1500',63,32,'','CN89ne','','','',234,'E51JD','',0,'20M',-1,'OC','','','','','','','',null,'','','','','','')
57 Query COMMIT
200809 20:30:14 57 Query START TRANSACTION
57 Query SELECT * FROM profiles WHERE visible > 0 ORDER BY nr
57 Query ROLLBACK
57 Query START TRANSACTION
57 Query SELECT * FROM profiles WHERE nr = -1
57 Query ROLLBACK
200809 20:46:14 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin <=14.225 AND b_end >=14.225) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='20M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='20M' AND mode='SSB' LIMIT 1
58 Query ROLLBACK
200809 20:56:48 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin <=7.009 AND b_end >=7.009) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=239 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=239 AND band='40M' AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=239 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=239 LIMIT 1
58 Query ROLLBACK
200809 20:57:09 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin <=7.015 AND b_end >=7.015) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 LIMIT 1
58 Query ROLLBACK
200809 20:59:21 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin <=7.015 AND b_end >=7.015) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 LIMIT 1
58 Query ROLLBACK
200809 21:02:50 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin <=7.18 AND b_end >=7.18) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='40M' AND mode='SSB' LIMIT 1
58 Query ROLLBACK
200809 21:03:24 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin <=7.177 AND b_end >=7.177) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='40M' AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 LIMIT 1
58 Query ROLLBACK
200809 21:04:13 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin <=7.012 AND b_end >=7.012) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=21 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=21 AND band='40M' AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=21 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=21 LIMIT 1
58 Query ROLLBACK
200809 21:19:05 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin <=3.842 AND b_end >=3.842) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='80M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='80M' AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='80M' LIMIT 1
58 Query ROLLBACK
200810 0:01:15 62 Connect root@localhost as anonymous on
62 Query flush local error logs
62 Query flush local engine logs
62 Query flush local general logs
1) I wonder why CQRLOG ceases to communicate with the MariaDB server?
2) I wonder if the 1:15am "housekeeping" log-rollover may be affecting CQRLOG?
-Gord VA7GP
Hi Gord!
Good questions!
Yesterday evening I decided to leave cqrlog running to see what happens. Unfortunately without debug option.
In my setup I use Maridb database server running in same PC (the "real one" at port 3306) that is replicating with my server MariaDB via home LAN.
I left DXCluster, bandmap,Wsjt remote with wsjt-Map, TRxControl,Rotcontrol,GridMap,both propagations, Grayline and reminder open with wsjt-x. That is my usual setup.
In morning, after about 12 hours, wsjtx was still running and wsjt-Map was showing decodes. Reminder had alerted (afrer 45 mins). Everything seems o be ok BUT: DXCluster was stopped and also BandMap was empty.
Cqrlog was still in full control and after resetting Reminder and disconnecting and reconnecting DXCluster new spots started to flow and BandMap started to fill again.
So it seems that the problem lies somewhere in DXCLuster. There has been complains about DXCluster connect(spot flow stops) before.
When looking at source DXCLuster uses Lazarus'es own lnet unit to make connection. Wsjt remote uses synaptic telnet unit.
The difference between them is that lnet can produce event when there is something in RX buffer. Synaptic does not have that feature and it must be polled by the host program to see has something arrived to RX buffer.
On the other hand I think that you (or someone else) said that debug still shows spots arrive but never printed to DXCluster window. That would prove that lnet receiving side is working and producing events but spot handling has something that fails.
In that point the communication with MariaDB comes in.
But how we could catch the problem?
It might even be a very small issue in source. But it can also be problem in Lazarus sql unit.
--
Saku
OH1KH
Hi!
Last night I had different setup.
I created a new log, imported settings from my regular log, except rig. I used #1 (dummy rig).
I left cqrlog runnig with only Band map and DXCluster open and connected. At this time with debug=1 and saving to file.
It has now run longer (over 12hours) than last test and it is still running.
DXCluster gets spots and band map is populated. Difference with Band map now is that it shows "all bands". At last time it was "current band".
This shows how difficult it is to catch the problem!
--
Saku
OH1KH
Weeee!
Even when all looked ok and new spots arrived and populated Band map after writing my last message I decided to close cqrlog.
Then: " TMySQL57 connection: Error execuitng query: MySql server has gone away"
The splash is still on screen and I can see new spots coming and Band map populating on the background.
When looking at debug.txt some oddities can be found. Like memory buffer overflows. They are from time after getting the error splash to screen:
TelThread.Execute - afwhere (callsign=
Colllsign= 'R8XT')
TUS3ITU') and (band = '2M')
Color for xd = '2M') and (mode = 'SSB')
and finally when aborting
[FORMS.PP] ExceptionOccurred
But I think loosing Database connection at close has nothing to do with DXCluster spot flow stop.
This is proper close:
select count(*) from cqrlog009.cqrlog_config
Saving ini file to database
1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
Deleting config file: 9cqrlog.cfg
Deleting config file: cqrlog.cfg
Closing dData
Closing ini file ...
This is MySql server lost , close:
select count(*) from cqrlog009.cqrlog_config
Here should be: "Saving ini file to database" and "MySql server has gone" happens at this time
1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
Deleting config file: 9cqrlog.cfg
Closing dData
Closing ini file ...
Closing dData
[FORMS.PP] ExceptionOccurred
And as said: despite the error splash spots were flowing at background.
I think that means we have two problems that may not be related:
- Why DXCluster spot flow stops ?
- Why MySql server connection breaks ? (and when? at 00:00 PC's time?)
--
Saku
OH1KH
This is not new. See three last comments: https://www.cqrlog.com/comment/1034
--
Saku
OH1KH
Found interesting things:
To keep database connection alive: https://mariadb.com/kb/en/mysql_ping/
Cqrlog actually have DBPingTimer that is enabled and running with period of 5 min (300 sec). But the ping procedure that should be run every 5mins is commented out. So there are no pings.
Instead there are settings like this:
MainCon.KeepConnection := True;
But when reading Lazarus/Freepascal definitions they say:
Description
KeepConnection is provided for Delphi compatibility, and is not used in the Free Pascal implementation of TDatabase.
If I understand this right there is no KeepConnection to happen, so ping is the way to keep it running.
I have now restored then out commented ping source and modified it a bit and will next test did it make any effect.
--
Saku
OH1KH
Hi, Saku:
Thank-you! I have downloaded / installed your latest 2.4.0(123) version. First comment: DXCluster seems to take a while (couple of minutes?) before any spots appear... I thought it was broken :-( but maybe this is a side-effect of the 5min ping change you made? But if I am patient during startup, eventually DXCluster spots appear.
I'll let things run a lot, over the weekend, and see how it goes...
best wishes,
-Gord VA7GP
ref (I used cqr2.zip for my 64-bit GTK2 system):
https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled
Hi Gord,
... have been very busy the past fortnight, so I didn't manage to test anything.
Is the updated Version still running stable in the long run?
@Saku: Do you know, whether an official new release is planned in the near future, and will this feature be "in"?
I shy a bit away from manually installing stuff on my "productive" box ...
Cheers, and 73
Stefan.
--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE
HI!
alpha 2.4.0(123) was not stable. At least here and at other ham near by who reported to me.
The ping causes (I believe so) several mysql database errors that were not there in (122).
I release (124) that has ping again disabled and it is up to date with official source (at date of last Friday)
I was away during weekend and now got new report that (124) has something with qsl label printing that (122) did not have. I have to look at it during next week.
I do not know release table. Depends how much Petr can spend time for cqrlog. Meanwhile we have to go with self compile from source or with alpha binary updates.
--
Saku
OH1KH
Hello Saku,
same issue here with 123 and 124 - loosing database connection!
Now I changed to self-compiled ok2cqr version (4cdbd2d) and all is stable again.
--
73 de Martin, DL1MTG
Hi Martin!
Funny!
I do not remember there is any difference now with Petr's source and alpha when talking about DXCluster part.
But do you compare alpha binary and self-compiled ok2cqr version?
What about if you clone alpha source from GitHub and compile it? Could it make difference as the alpha binary is compiled with Fedora 31?
--
Saku
OH1KH
Hi Saku,
some time earlier I've had problems with the pre-compiled versions - all qt5 ones.
So I started to use self-compile cqrlog from source.
Today I compared v126 qt5 pre-compiled
with v126 qt5 self-compiled and debug=1:
=> pre-compiled: begins to start, cannot find sql-server (only one try) it aborts
=> self compiled: begins to start, cannot find sql-server (frist try)... next try: startup successful!
I'am using Linux Mint 20 Ulyana, 64Bit with Lazarus 2.0.6
--
73 de Martin, DL1MTG
Ok Martin!
I nearly expected that!
As cqrlog does not use static libraries it may happen that precompiled does not start if differences are too big.
That's why we should have script that first checks and loads fpc, Lazarus and everything else needed and then launches make at cqrlog source directory.
Like for example HP printer software is installed, from script not from package.
--
Saku
OH1KH
Greetings.
Is there simplest way for deleting unwanted entry from log_list
other than tinkering directly in cqrlog_common database?
See attached picture log_list.png (SP2L-trash).
Take care.
File:
Best regards.
Tom - SP2L
https://www.sp2l.ampr.org
[Edited]
Greetings.
Is there simplest way for deleting unwanted entry from log_list
other than tinkering directly in cqrlog_common database?
See attached picture log_list.png (SP2L-trash).
Forgot to mention that "Delete log" option
in CQRLog "Database connection" utility doesn't work.
Take care.
File:
Best regards.
Tom - SP2L
https://www.sp2l.ampr.org
Answer is no simple way.
Just use sql interface and remove it.
I have also one log that I have messed up. #5 It does not show on list, so no delete with delete button.
And a new log creation with #5 is impossible.
I know I could fix that manually from sql console but I have been too lazy to do it... I just change offered number 5 to another in new log creation.
--
Saku
OH1KH
Hello Saku.
Looked a while longer at issue in question.
"Delete log" item on "Database connection" window
doesn't say "Delete database"!
On previously attached picture "log_list.png"
there is _NO_ database named "cqrlog002"
but there is entry in MySQL log_list table:
id_log_list 2
log_nr 2
log_name "SP2L-trash"
As a consequence this is displayed on "Database connection" window,
whereas in reality MySQL database "cqrlog002" (log_name - SP2L-trash) doesn't exist!!!
So, no way to delete something simply non-existent, no doubt!
But from the other hand, on "Database connection" window
it is not plainly visible as there is "log_nr 2" "log_name SP2L-trash"...
At the moment I do not remember chronologically
how it happen that I do not have MySQL database "cqrlog002"
and still having "log_name SP2L-trash"...
Deleted entry "SP2L-trash" from MySQL database
thus clearing displayed log list in "Database connection" window
and dismissing minor issue, Hi!
Would it be feasible to equal MySQL database name
with CQRLog log_name?
Take care.
File:
Best regards.
Tom - SP2L
https://www.sp2l.ampr.org
Yes yes!
But be aware that it can happen also other way round:
There is no log number X, it offers the X when create a new log but you can not create it because X "is in use". But still there is no name on list with number X and no database in server.
So it is no wonder that you have name in list and it is pointing nowhere. It just the same thing. Opposite.
Naming databases as "cqrlogxxx" makes it easy to handle them inside the code. If databases have "wild names" source should be different.
For normal use this is insignificant. It works fine, so why touch to working code.
The mess up happens usually when cqrlog has died at critical section. Power failure, network breakdown (if database is at different machine) or unexpected behavior of user.
The code is not fool proof (it would be much bigger).
Some examples:
If you go from NewQSO to File/Open or create new database you can delete currently open log. Or you can import log settings there for currently open log.
Both are fatal and fixed now in latest source (but all package installs still carry these bugs).
And sure there are lot more things that user can do, but he should not and that is not expected to happen.
Just found that mark your logged qso as "Qsl sent", but then later mark it back to empty. qsl_s is empty, but qsl_sent_date still carry the date qsl was marked to be sent at first time.
How ever this is not fatal and needs no fix. Except for perfectionists.
--
Saku
OH1KH
I also have the famous "TMySQL57Connection : Error executing query: MySQL server has gone away." error. I see the same behaviour as seen by many, namely that it is in the morning after leaving WSJT-X and CQRLOG running over night this pop-up. In order to trace the problem I did first run CQRLOG in debug from the console. This revealed nothing more than mentioned above.
Then I started Wireshark checking all mysql traffic.
Some findings:
1) When CQRLOG crashed there were no traffic from the PC running CQRLOG to my generic MySQL server. Does this mean that it is not the server that times out the connection? I will try to do some further investigations on the matter.
2) When CQRLOG starts up there are actually FIVE different threads setup, i.e. there are five different logins and acknowledgements from the server back to the CQRLOG. Could it be so that not all of them have a keep alive timer? I have not seen any kind of re-connection / re-establishing over the MySQL connection when leaving CQRLOG it running for a long time, i.e. over night.
I am using 2.4.0 (001) 2019-10-27 on a Linux Mint 20 Cinnamon and the MySQL server on a Debian 10 VM
/Thomas
---
Thomas
SM0KBD
Hej Thomas!
Can you check that there was not linux autoupdate during the night?
I do not use autoupdates, but just two days ago I started update manually. Quite manu updates to various programs including MariaDB.
While update was running on one desktop I had cqrlog on other and worked with programming on third.
Suddenly I got that same splash "Maridb server has gone away".
At that time I switched to first desktop and saw that script had just run MariDB part of update.
Could it be same problem with your system, or does it happen so often that it can not be system update during night?
--
Saku
OH1KH
Hej again!
As always, I forgot another thing.
If it happens always during night, could it be the time server system rotates it's daily logs? (and breaks the connection somehow)
If MariaDB server network connection disappears silently (at network's or server's side) cqrlog thinks it has still connection. Then next query will produce timeout.
Somehow I remember that freepascal/Lazarus SQL unit can not recover connection if it breaks. I'm not sure, it has some time since this was discussed.
Or was it so that there is SQL keepalive command to make Delphi compatibility, but actually it does not do anything in FPC?
That can be found by some Googling.
This kind of problem is very difficult to track.
--
Saku
OH1KH
Hi Saku,
thanks for your comments!
I am looking further into this problem. But as it take some time to get it to crash I might not have more info for some more days.
Anyhow:
1) It happens every night, at least until now. Which probably roll out the auto-update.
2) I have now disabled the logrotation for the mysql error.log. This could be a problem so lets see how the disabling impacts the crash.
3) There is no apparent communication via tcp using the mysql filter in wireshark when it crashes.
4) There is however one thing in the mysql error.log which I have not yet correlated to an action in cqrlog.
"020-11-19 16:16:38 8396 [Warning] Aborted connection 8396 to db: 'cqrlog001' user: 'cqrlog' host: 'xxxxxx' (Got timeout reading communication packets)"
5) The "Aborted_clients" status counter in mysql is incremented when it crashes.
That is all for now! :)
---
Thomas
SM0KBD
Hi Thomas!
This is a very long thread and I tried to find earlier discussion about this subject without results. Just understanding that they all are in this thread.
I tried to do something in August, but that code was unstable and I did give up then.
I hope yo can find something new from this bug.
--
Saku
OH1KH
Shall we make a new thread out of it?
---
Thomas
SM0KBD
Was a new thread started?
Orb
WK0DX
No, there was no new thread started!
---
Thomas
SM0KBD
I'm having so much trouble with abort or ok dialog on any version later than V122 that I have went back to v122, Mariadb, JTDX or WSJT-X, Mint 20. Makes no difference which one of my databases I open. When I close JTDX, I get the abort or ok dialog. Or after clicking OK to close JTDX or WSJT-X and it closes, then get Abort or OK in order to close CQRLOG. Getting frustrating.
OK, I just saw where 2.5 is out. I'll try that.
Hi!
Set preferences/fldigi/wsjtx interface so that you do NOT start wsjt or jtdx when going to remote mode.
Open jtdx or wsjtx manually from start menu or icon and then set remote mode in cqrlog from it's menu or with Ctrl-J
Remember also that when you use cqrlog and jtdx/wsjtx at same time with your rig settings both will want to access your rig via same serial port that causes problems. See this https://github.com/OH1KH/cqrlog/blob/loc_testing/compiled/setting_rigctl... if you have not already done so.
--
Saku
OH1KH
Thanks for the reply Saku. I'm already starting CQRLOG and JTDX manually and using crtl J to start wsjt-x remote on CQRLOG. Also no rig settings enabled in CQRLOG, only in JTDX.
This is the bash script I use to start everything. When it exits both programs it makes a backup of the wsjt-x_log.adi file that JTDX uses to another drive so I have two copies.
#! /bin/bash
/usr/bin/cqrlog &
/usr/local/bin/jtdx
cp -R /home/orb/.local/share/JTDX/wsjtx_log.adi /media/orb/5F1368BF498CBD32/ham_radio/Logs/wsjtx_log.adi
I'm not having any luck installing a prebuilt v2.5.0
Orb
WK0DX
Ok!
I think the problem is that cqrlog without any rig settings cannot run wsjt remote properly (I have never tested)
Try to configure your rig to cqrlog. When it works open jtdx and select "Hamlib Net rigctld" as rig model
and the write to "Server address" (that previously hold your rig's device name) localhost:4532
Start cqrlog first manually and see that TRXcontrol shows frequency.
Then start jtdx manually and see that it shows same frequency and that you can change bands from jtdx
If that works close both and try your script next.
You may have to add
sleep 5
after /usr/bin/cqrlog & - line to give cqrlog time to start rigctld.
When it is started in that way do you still get errors?
--
Saku
OH1KH
Thanks for the help Saku.
Ok, rig control works that way. And I can control the rig using JTDX, CQRLOG correspond with the change. That all looks good. I did add the sleep 5 after my bash script launches CQRLOG. Using v122 of 2.4.0 I have no errors on exit. When I switch to v127 then I get the errors back. Abort or OK when closing JTDX and also when I goto close CQRLOG.
I receive an error message in the terminal window that my bash script was running in:
WARNING: TfrmNewQSO.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event?
Closing ini file ...
Any ideas? I really do appreciate your help.
Orb
WK0DX
Actually, I might have spoken too quickly. I'm not thinking rigctld is running when I manually start CQRLOG in a terminal with debug =1.
Here is what is in the terminal window that pertains to rig control:
Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctld
RigCtldArgs:-m 134 -r /dev/ttyUSB0 -t 4532 -s 38400 --set-conf=data_bits=8,stop_bits=2,serial_handshake=Hardware
RunRigCtld: TRUE
RigDevice: /dev/ttyUSB0
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 1
RigSendCWR: FALSE
RigId: 134
Starting RigCtld ...
rigProcess.Executable: /usr/bin/rigctld
Parameters:
-m
134
-r
/dev/ttyUSB0
-t
4532
-s
38400
--set-conf=data_bits=8,stop_bits=2,serial_handshake=Hardware
rigctld failed to start!
1
2
3
4
5
6
1
2
3
4
5
6
Orb
WK0DX
HI Orb!
Fine to hear about your progress with programs.
First:
If you like to use my test binaries (you have ver122 & 127) please update! Latest is (v 135). There is also official cqrlog 2.5.0 release if you like to use that. (v135) and official 2.5.0 are quite near the same.
Second
If you have updated you linux lately be aware that new hamlib has different rig model numbers. They start from 1000 so you rig will be -m 1034. With latest versions of cqrlog it is enough to go prefreneces/TRXcontrol and reselect rig from rig selector's list.
Third
It might be that rigctld has left running and you see from debug that it does not start when cqrlog starts. It does not start if there is already one rigctld running.
When cqrlog closes it should also close rigctld it has started. Sometimes it happens to left running.
you can check it from command console with:
ps ax | grep rig
And remove with
killall rigctld
So many times that linux says "no process left"
I'm not very sure what your script really does as it starts cqrlog as background process (with & at the end of line).
WIth settings where rig is defined in cqrlog preferences and jtdx uses rig "Net Hamlib rigctld" you could also try
cqrlog prefrences/fldigi wsjt interface check the checkbox "Run wsjtx after entering to remote mode for wsjtx" and set path to wsjtx as path to jtdx
This way they start in proper order.
Then you can add the copy of jtdx adi to cqrlog's close script.
~/.config/cqrlog/stop.sh
If that does not exist create it, add #!/bin/bash and your copy command lines, save and set execute bit with chmod a+x ~/.config/cqrlog/stop.sh
This script should be run at cqrlog close.
So you do not need your script at all.
--
Saku
OH1KH
Thanks for your time Saku. I appreciate your help. I upgraded hamlib to v4 and now I have rig control working in V135. I start JTDX using remote in CQRLOG and I added a stop.sh bash script to copy my database and provide a backup adi file on another drive.
I still have the Abort or OK dialog box when I close JTDX or CQRLOG.
"I'm not very sure what your script really does as it starts cqrlog as background process (with & at the end of line)."
It manually starts CQRLOG and JTDX and when those are closed copies my adi file to another drive.
without the & at the end of the line JTDX will not start until CQRLOG is closed.
Again, I appreciate all your help.
Orb
WK0DX
Hi Orb!
OK nice to hear it works that way!
One user here in OH had similar problems. I made a test compile for him using Mint20 instead of Fedora32 and using the official source (without my additions that exisit in my testing v135).
He reported that now all works ok.
The file is still in my Google drive. You can test with it if you like.
https://drive.google.com/file/d/1dOcHaRt7-QQyNPz5lh7MKbHP2l7ct-n9/view?u...
Download zip to somewhere (I suggest /tmp) . Stop cqrlog if running.
With command console make a backup copy:
sudo cp /usr/bin/cqrlog /usr/bin/cqrlog_old
Extract zip directly to /usr/bin after you have first made the backup copy:
unzip /tmp/cqr.zip -d /usr/bin
(say "y" when it asks permission to overwrite exsiting)
Then you can start cqrlog as usually and see if it still has those Abort/OKs
If you want return back to old cqrlog close cqrlog if running.
Remove current one:
sudo rm /usr/bin/cqrlog
Copy backup version to current
sudo cp /usr/bin/cqrlog_old /usr/bin/cqrlog
You still have also cqrlog_old remaining, just for sure,
Start cqrlog.
--
Saku
OH1KH
Hi Saku,
I downloaded the file from your Google drive. I installed it after making a backup. All is working fine. I no longer have the Abort or OK dialog when closing CQRLOG or JTDX.
I really appreciate your patience with me. Also I appreciate all your help.
Best 73 my friend and Good DX,
Orb
WK0DX
Is there still no resolution to the database connection timeout issue? Curious, as this is the only thing that plagues me with CQRLog.
Pages