Hi,
after an upgrade from KUbuntu 18.04LTS to 18.10 no spots are displayed in the DX cluster window after a few minutes. The previous spot list "freezes".
The Telnet window is used with "telnet.reversebeacon.net" as "DX-Cluster". After restarting CQRLog, the spot display will work again for a few minutes before freezing again.
Disconnect and reconnect while CQRLog is running do not solve the problem. The login to the DX cluster is executed, but the spot is not displayed.
The problem only seems to affect the Telnet window.
What could be the cause?
Thank you in advance,
Wolfgang, DL2KI
Hi!
>Disconnect and reconnect while CQRLog is running do not solve the problem. The login to the DX cluster is executed, but the spot is not displayed.
Do you get login prompt with reconnect? Or is it so that you just press connect/disconnect button, but nothing happens? That indicates you do not actually have reconnected.
Cqrlog telnet cluster is missing a check timer for connection. If connection fails because of internet, ethernet of Wifi failure, and you are not sending anything, just watching spots, you can not see the break from any indicator. Spots just stops to flow. The button (connect/disconnect) does not change.
First I would study the internet connection. Start command console and make telnet session manually to reversebeacon. Leave it running and start cqrlog's DXCluster too. When (if) Dxcluster at cqrlog fails does the command console telnet session still run ok?
These "after upgrade" failures can be mysterious, but checking the connection this way is a good start. If the failure is not there next it would be nice to know what have changed between 18.04 and 18.10. Specially network side.
--
Saku
OH1KH
Hi Saku,
unfortunately, at the moment I can only present the facts again, because I cannot recognize the cause. Maybe a problem with the compiler or the libraries? Are the spots buffered in CQRLog or passed on directly?
After Disconnect / Connect the login message appears. The display then stops.
Please enter your call:Local users = 155
Current spot rate is 6384 per hour
DL2KI de SK1MMR-3 11-Jan-2019 08:27Z >
After restarting CQRLog, the spot display works, but freezes again after a few minutes (Or a certain number of spots?).
With the Telnet client on the command line, the spot display runs smoothly. There are no problems here.
After installing the CQRLog beta version, the same behavior occurs.
The same behavior was observed after installing the Kubuntu backports in October.
See my post "Kubuntu 18.04-LTS, information: Kubuntu Backports Issue".
So I first went back to version 18.04 LTS.
Here the Telnet DX cluster works again without problems.
Maybe a solution can be found.
73, Wolfgang
DL2KI
HI!
Might be hard to find if console telnet works, but cqrlog telnet freezes.
Must be a library problem, but where?
Spots are passed directly. But do not go through if frequencies are set to zero. See:https://www.cqrlog.com/comment/7123#comment-7123
But this can't be same reason.
It could be some kind of tcp stack overflow. But on the other hand it should happen also with console telnet.
Sorry but this seems to be too rare and complicated problem to resolve "as remote".
--
Saku
OH1KH
Hi,
yes, I can't find a solution to that either. At the moment I will stay at 18.04 LTS.
The problem seems to be an isolated one so far.
73, Wolfgang
DL2KI
Hi,
today I installed "Linux Mint 19 MATE 32-bit" on an older "Lenovo T60" laptop to test the telnet function of CQRLog.
On desktop 1, CQRLog and a terminal with a telnet session were running in parallel. In both clients "telnet.reversebeacon.net:7000" was running.
After some time the output freezes in the CQRLog DX-Cluster window. So the same behavior as under "Kubuntu 18.04LTS with Kubunu backports" or after an update to "Kubuntu 18.10".
The cause remains unclear. Possibly a problem with the telnet lib of Lazarus (INet).
73, Wolfgang
DL2KI
Hi!
Does cqrlog work otherwise, but just DXCluster freezes?
Could you start cqrlog from command line as:
cqrlog debug=1 > /tmp/debug.txt
and then add the file to your next message.
It would be good to know the point in file where telnet stopped.
You can indicate it as follows:
open console telnet for reversebeacon
open dxCluster for reversebeacon.
Set focus on NewQSO window and at the time you notice telnets have diffrence press Ctrl+J (open wsjtx remote mode).
Opening that leaves clear mark to debug file (if cqrlog just operates properly after dxcuster freezes).
It may be that it does not show anything, but it is the first try to catch this error.
It could be overflow of stringList that is used to print DXCluster lines. Reversebeacon outputs quite lot of lines.
But it is strange if it works with old OS,but not new and the cqrlog binary is the same.
--
Saku
OH1KH
Hi Saku,
i will try your suggestion during the day and upload the log file. Maybe there will be some information.
CQRLog runs here on an Intel Core I5-7500, 3.4 GHz, 8GB RAM. The freezing of the Telnet output does not occur here under "Kubuntu 18.04LTS". Nevertheless the effect occurs under "Kubuntu 18.10" and "Linux Mint MATE 19". It is therefore unlikely that the PC or OS is too old.
I already described a similar problem in an earlier post, because the output in the DX cluster window doesn't work properly either, e.g. for contests with many spots.
https://www.cqrlog.com/node/1925
Here it actually seems to be an overload because the output of the lines is mutilated. A freeze could not be observed.
The effect is limited here only to the DX cluster Telnet output. Otherwise the software works as before.
Maybe it is possible to use a simple! pre-filter, which for example only lets spotters from the EU through. There are similar settings for many DX clusters. Usually spotters from OC are not interested here. This could perhaps reduce the load for further processing.
Example (DX-Watch.com):
"de continent: EU - Europe / band: 80m,60m,40m,30m,20m,17m,15m,12m,10m / mode: cw"
I use RBN, because it shows QSO partners in CW in DL and Europe very fast, which I can reach then also.
OK Saku. First of all thank you very much for your efforts.
73, Wolfgang
DL2KI
Hi Saku,
in the attachment the debug file and a screenshot of the frozen DX cluster window.
The calls can be found here in the debug file:
DX de VE7CC-#: 3522.0 - Line 54134DX de VE7CC-#: 7933.0 - Line 54137
DX de WE9V-#: 3522.0 - Line 54140
DX de BG7IBS-#: 7925.1 - Line 54145
DX de WATLNW-#: 7922.0 - Line 54146
DX de WA7LNW-#: 3522.0 - Line 54147
DX de F5RRS-#: 7925.1 - Line 54318
I hope the file will give some information. However, I can create more debug files, maybe on weekends with higher traffic.
73, Wolfgang
DL2KI
File:
Hi!
I have done a look of your debug. Also found lines:
Socket created!
Reuse enabled!
Bind issued 127.0.0.1:2237
That indicate wsjt-x remote getting on.
Lines you state are few hundred lines above.
After that it seems that telnet is still running.
TelThread.Execute - before Synchronize(@frmDXCluster.SynTelnet)
TelThread.Execute - after Synchronize(@frmDXCluster.SynTelnet)
pairs stop near that time. That might indicate something, but needs more source investigation.
--
Saku
OH1KH
Hi Saku,
in the attachment the screenshot of the frozen DX cluster window.
73, Wolfgang
DL2KI
File:
Hi Saku,
thank you very much for your information. Maybe you will find the cause of the problem.
"wsjt-x remote"? I don't use digital modes here, only CW. Therefore I have to look up, what it has with it on itself.
If you need more or other debug data, please contact me.
73, Wolfgang
Hi!
I have been busy with other things, but today I made a quick test and found out that Telnet freezes also here (Fedora 28 x_64/LXDE).
It is just question of overflow, I think.
Tel.thread sync is lost after a while. Sometimes connection gets to disconnected state, but not always.
When the sync is lost debugging shows that spots are still received from reversebeacon.
When that situation happens sometimes a line or two with CQ and a number (freq?) is shown. but no other information.
So this needs lot more testing.
Good side is that it seems to be rather easy to repeat when spot rate is moderate or high.
--
Saku
OH1KH
Hi Saku,
nice that you could reproduce the behavior now.
Strange, that this worked under "Kubutu 18.04 LTS" and before without any problems. What has changed in the distributions?
But no matter. Good, if CWRLog improves a bit again, if you found the bug.
Thanks for your work on the software.
73, Wolfgang
HI!
Not directly perhaps releted to this, but telnet dropouts, I found out some weeks ago that if DXCluster alerts are used and the alerting script for some reason fails this ends telnet spots to stop.
Funniest thing is that if you change dxcluster to another same continues. Looking like all telnet dxclusters are out of service.
See: https://github.com/ok2cqr/cqrlog/issues/425
This shows how sensitive dxcuster connection is that it does not recover without program reboot.
There might be also other similar bugs still that are hard to find in normal way.
--
Saku
OH1KH
Hi,
I have compiled and tested CQRLOG from the current sources "https://github.com/ok2cqr/cqrlog".
It looks like the freezing of the Telnet DX cluster does not occur now. The bandmap works with the Telnet DX cluster now as well.
The callsign alert feature was always on for me, but was not associated with the problem.
Apparently the problem with the pull request #428 has now been solved.
This thread is thematically related to the problem and can therefore be merged with this thread.
https://www.cqrlog.com/comment/9808#comment-9808
Unfortunately the edit functions in the forum are very limited, so I can't do this myself.
Thanks a lot, 73, Wolfgang
DL2KI