Hi!
I have had an issue appearing every now and then in the recent ver 2.5.2 but also in earlier releases, Ubuntu 18.04 and 20.04, on different machines.
If I open the log window and put CTRL-F and search for a call sign or partial call sign it sometimes happens that the search window goes blank and it is not possible to get out of this state without killing the program. Its not possible to click oneself out of it. CQRLOG starts up nicely again and all seems fine.
After a while I have noticed that the database is slightly messed up, maybe because of having to kill the program. If I have a QSO for example with V6EU in the log and then rebuild the DXCC statistics, V6EU is no longer referred to DXCC V6, it toggled to something else, in this case E51(N). An E51(N) QSO gets instead "V6". If I rebuild DXCC stats gain these two toggle again. And there is always at least one QSO having the wrong DXCC assigned. Its not a big deal, I just create a new log and all is usually fine again.
Has someone else experienced this state when searching the log?
Yes, I have had the crash situation before. I used to use it when entering QSL information when I received a card. I now use the filter option instead, and I have a side utility I wrote in Python to do casual "quick searches" in the log while operating so I don't interrupt things while running WSJTX, so I haven't witnessed this in a couple of years or so.
The behavior was exactly as you describe - the search box stays active and cannot be closed and the only way to return to operation is to kill CQRLog. It doesn't happen every time, but often enough to be a big nuisance.
I have not noticed the second issue you described. I don't think any of my DXCC stuff changes.
I thought I brought this up several years ago, but searching the forums doesn't turn anything up about it, so maybe it was an email exchange.
HI!
This is a long known problem. Empty error splash may also appear then.
How ever very it is hard to trace. I have done several tries by instructions I have received from people having this problem.
I have never managed to reproduce this reliable. I think there are two queries using the same fpc query definition at same time. And when this happens in suitable situation crash does happen.
Maybe it is timing critical.
I use MariaDB database server running at localhost port 3306. So logs are in local machine anyhow, but I do not have "save log data to local machine" checked and Cqrlog does not start a new sql server running based in ~/.config/cqrlog/database folder.
Than may make difference.
I would be happy if someone can show me a reliable way to reproduce this error so that it can be traced.
There are also other weird things. Here few:
- Getting error splash "2023-12-15" is not valid date. Date may be what ever and it looks like perfect format. Always.
This happens to me maybe once in 2-3 months, too seldom to get traced. And it cannot be reproduced.
I have seen this happen also in another machine when giving remote support. Mine is Fedora 38, supported PC Fedora 39, same Cqrlog version in both.
-In conjunction with this, but not necessary at same time, it can happen that when Cqrlog is opened there are no qso dates in Qso list.
Then saving a qso can not be done and may lead to "wrong date format" splash.
Both those are corrected and disappear when Cqrlog is restarted.
- Then I have seen in Fedora39 / 2.6.0(121)_QT5 that at start small window frame appear over the starting splash CW key image.
It disappears immediately, before image disappears.
In other just similar Fedora 39, as well as my Fedora 38, this does not happen. All are running same QT5 version of Cqrlog.
-I have got report that when using Contest window and save a qso cursor does not come back to Contest window/Call column,
but goes to NewQSO/Call column.
I was unable to produce that with my Fedora38. But when giving remote support for one Fedoa39 I saw that happen.
It need QSO list and Contest window being open together. How ever this disappears if both windows are closed and then reopened.
This happened with QT5 version of Cqrlog.
All these are bugs that are had to reproduce several times so that tracing could happen.
I am more than happy if someone finds way to reproduce these 100%, always.
--
Saku
OH1KH
Thanks, Saku! I seem to remember more of this discussion now. I am also not able to replicate this reliably. It only happens sometimes and since I have been easily working around it for years, I'm not all that concerned about it. I mainly wanted to let SM6VJA know he's not alone. ;)
Merry Christmas
Dave
Thanks for info.
I also had the dates disappear from the QSO list. My feeling is that this mostly happened to me if I start CQRLOG too soon after computer start-up, just when the desktop appears and the drive is still furiously accessed. BR Mikael SM6VJA
Mikael SM6VJA
Hej Mikael!
Nobody has never told that for me. At least I do not remember that.
Now I know it really happens also to someone else.
It might be related to PC startup as also here that happens most often when Pc is started and Cqrlog accessed right away.
How ever I doubt it would be hard drive as I have fast SSDs in all computers.
Our PCs are usually running local time and Cqrlog uses UTC for logging and that makes me think it could be laying somewhere in date time routines. (When we see "invalid date splash").
On the other hand qsos already in log have steady date and time that do not need conversions any more.
It leaves "empty date" problem in Mariadb (that I do not believe) or the unit that connects Mariadb and Cqrlog, that is more likely.
I there just could be a way to repeatedly reproduce it might be catched.
--
Saku
OH1KH
Hello,
Here problem exists since the beginning of CQRLOG use.
The problem appears after several search requests.
I try to close the windows but it doesn't work. I may have to click on QUIT (New log window), click several times to close this empty warning and then it disappears but it appears again when clicking on QSO list window (the one with CQRLOG for Linux as title)
I launch cqrlog with debug=1 and I have this message :
WARNING: TGtk2WidgetSet.InvalidateRect refused invalidating during paint message: TDBGrid
Hope it could help.
73's
Herve
(Happy New Year 2024 !)