HI !
I like to have some test reports about new alpha version.
I have made state addition to CQ monitor but it needs "pileup" to see how slow it may be when there are many US stations in the band at same time.
It can not be tested here at my location.
I need testers who:
- have working cqrlog now and can(and will) do complete backup from it at least copying ~/.config/cqrlog folder with logs and settings
- work FT8 or/and FT4
- are interested in getting all USA states worked
- live in USA or place where several US stations can be heard in bands (Here conditions are so poor that just few can be heard from time to time, but lot of EUs)
- can read and understand my INSTALL.TXT and REPORT_ABOUT_THESE.TXT
-possible can compile from GitHub source, or otherwise can use precompiled 64bit binary fie.
See: http://www.saunalahti.fi/~sakny/bin/cqrlog2/ for binary files.
Or the source: https://github.com/OH1KH/cqrlog/tree/states
(Binary files also have sources: https://github.com/OH1KH/cqrlog/tree/filter_to_date and https://github.com/OH1KH/cqrlog/tree/rtty_data included. I.E. it is the same I'm using daily here)
Hello Saku,
I've installed your latest CQRLOG version 2.4.0 (126) since the standard one has a problem when using FLDIGI (Frequency went not updated into xlmrpc windows!).
But I notice a weird issue with your version:
When I start CQRLOG, WSJT-X remote then I cannot unselect the mark sign (to exit from remote, for example if I need to edit a QSO saved in the log) so CQRLOG send a warning of DB corruption risk!
If I don't find a solution to this I will roll-back to CQRLOG standard version.
Thanks for your attention!
73 de PY1ZRJ
Hi!
Thanks for reporting.
Did you mean that you can not uncheck the "Offline" (red background) checkbox while wsjtx remote is on?
There is a bug: you should not be able to change checkbox while remote is on. It is not safe. How ever when you uncheck the checkbox and it (turns to white) you still get warning "Log is in remote mode....."
I must lock the checkbox when any remote is on. That is the way it should be.
I do not have standard (meaning old version from package) to test how that was working.
If you need to edit a call while in wsjt-x remote you can just disable remote with Ctrl+J, do editing and return back to remote with Ctrl+J.
Of course you should select not to run wsjtx when remote is entered. Just start it manually as own process than you can freely use Ctrl+J in the middle of period and if you are fast you do not miss any period.
======================
If the question is about checbox at NewQSO/File/Remote mode for wsjtx it should work normally (at lest it does here).
If you need working fldigi xmlrpc but do not need states for wsjtx you could try to compile official source.
See the end of this message (from line "If you have running previous installation ...") https://www.cqrlog.com/node/2984
It might be that ready compiled version does not work properly in others Linuxes than Fedora32 that I have used for compile.
Compile is not difficult and offers all latest fixes.
--
Saku
OH1KH
Good morning Saku,
It's necessary to clarify the two points:
Let's rename the CQRLOG official branch as "CQRLOG-O" and CQRLOG modified by you as "CQRLOG-S".
- With "CQRLOG-O" the check/uncheck of WSJT-X remote is working always without any problems and the "Warning DATABASE risk corruption" never pops-up.
The problem with this version is that xmlrpc functions works only partially: the frequency field doesn't get updated automatically when you change the radio VFO or you put the frequency directly on FLDIGI.
- With "CQRLOG-S" instead, once you check the WSJT-X remote (CTRL-J) whenever you attempt to uncheck it as well as if you try hit CTRL-J or even if you try to close WSJT-X from it's main window, you always gonna fail and a "Warning DATABASE risk corruption" pops-up.
The good of your version is that with FLDIGI the xmlrpc window get all the fields filled automatically.
Note: I normally use to start WSJT-X as child process of CQRLOG, or better I start it from CQRLOG, I never or rarely I've started WSJT-X directly as a separated process.
I'm using Opensuse Tumbleweed here BTW.
Thanks and 73 de PY1ZRJ
Hi!
It might be that alpha compiled with Fedora32 does not work properly in your linux.
That is why you should consider to compile it by your self from Pet's GitHub source. That source has all fixes, also the xmlrpc fix, up to current date.
Dig the list from here https://github.com/ok2cqr/cqrlog/commits/master down to the release of 2.4.0(001) and you see how much is fixed after last official release.
Compile is not difficult. See the linked message that I sent in my last msg.
My recommendation is not to start wsjtx as child process. If cqrlog dies (and it does it in the middle of qso by Murpy's law) you will loose wsjtx. If it is started separately it stays running if cqrlog dies away.
Fortunately after cqrlog versons > 2.00 these problems are quite rare.
--
Saku
OH1KH
Good morning Saku,
Thanks for your directions and contribution to CQRLOG<--->WSJT-X echo system.
Yesterday I "git cloned" cqrlog and installed it very easily. With git version xlmrpc is working as expected and I also can enable/disable WSJT-X remote on-the-fly so currently it looks perfect for my usage.
The point here is ease: is good to launch an environment (CQRLOG/WSJT-X/FLDIGI...) by a single common place instead to launch each process separately, IMHO.
I've also replaced the two files ".pas" in the source of CQRLOG responsible for the logs upload onto HamQth, HRDLog, ClubLog since the frequent upload failures are very annoying.
With the modified .pas files: fLogUploadStatus.pas and dLogUpload.pas by the contributor phl0, the process appears a bit better less stable, but the error message "Upload Failed Check Internet Connection" persists. I think that CQRLOG developers should be review the code for this function because it doesn't look reliable.
Best regards,
PY1ZRJ
Great!
Self compiled version is the best one as it fits to own system. And it really is not complicated (I'm bad to criticize since I have used Linux so long, but even if I try to remember times in beginning it is still rather easy job)
I have here version (127) that is not yet in Git. I was requested to add a property that prevents uploading to clublog after qsl is marked as received.
It growed a bit and now there is selection to flush all pending uploads (kind same as mark al qsos uploaded, but does it a bit different way)
And then preferences has
"Ignore changed caused by QSL changes (+label prints)" and "Ignore changes caused by QSO edit" checkboxes.
How ever I can not test that because I do not use any club etc. logs and so the release was delayed. How ever I have not received any bug reports from user that wanted it, so I think it works ok.
--
Saku
OH1KH
GM Saku!
Yes, everything is running smooth now but logs upload section is still not reliable and straightforward!
Beside the process being unstable during the upload (especially if you need to upload hundreds of QSO) there is also a part very weird and annoying which is when you edit some QSO by hand in CQRLOG and then click the Online Log--->"upload all changes" again...
Boy! that's a real nightmare because it is not rare the case wherein CQRLOG starts a crazy process (to my eyes at least) of deleting/updating every and each QSO!!! Also the ones that you weren't touched!
When this occurs I interrupt the automatic logs upload, export the log in ADIF format and go uploading on each online log manually!
Best regards!
PY1ZRJ
Good morning!
I can confirm what PY1ZRJ has pointed out regarding wsjt-x: I use jtdx and when I click ctrl-j command to disengage cqrlog from jtdx the warning message pops-up and continues to pop-up even if I manually close jtdx. It seems as if cqrlog would go on listening to jtdx (the “call” window reamains greyed with the wsjt-x remote writing). Once closed jtdx I have to kill the cqrlog process clicking abort to terminate it. I use the leatest version of jtdx on Ubuntu Mate 20.04. Despite this strange behavior the signal reports from jtdx to cqrlog problem of the stable version seems to have been fixed.
Best 73!
Andrea
IU4DEG
Hallo!
Compiling cqrlog on my distro seems to have solved the problem. Thanks for the hint on how to perform this task.
Best 73
Andrea
IU4DEG