Hello everyone
i am using wfview and i really like the project.
Okay, but I have a problem.
I have an IC7300 and I connect it via USB.
What happens to me is this:
I start wfview on the computer that serves as my server and network the data to a second computer.
Everything seems to be working fine, but every now and then I lose the signal to the remote computer.
If I look at the computer server, everything works, but I can no longer connect to it remotely.
I also noticed that if I turn off wfview on the server and turn it back on it doesn’t work. In fact, if I do “netstat” I still see the udp ports open, even with the “off” program. i have to kill wfview and restart it, and it works again remotely.
it’s very frustrating, because I’m unlucky that it almost always happens to me in the middle of a qso.
I tried with two different servers, one is an intel i3 with ubuntu 21.04 and the other is an rpi 4, with totally virgin raspbian. The result is the same.
I’ve changed the audio encoding type, or buffer, but it looks like what’s left dead is the wfview network server.
the versions have been 1.1, 1.2c and finally 1.2d. I installed them both with the precompiled executables and via the github installer and compiling on the machine itself. I have not noticed any behavioral changes in any case.
The same thing happens to me with various clients, windows or linux, via lan or from the internet. it works well, perfect, but at some point the server stops responding …
sorry for the length of the message, but I tried to explain it as best I could.
And forgive the English. it is not my language.
eb3AM
OK,
I have watched and re-watched the forum comments and people are not complaining about connection errors.
So I thought it was a problem of mine, of my setup.
I put wfview in debug mode on both the client and server side.
I started playing remotely, changing frequency, tx, rx … etc and nothing happened. Everything worked fine.
Finally I remembered that today, at home, there is no one, and therefore no network consumption, beyond the small IoT and wfview.
I thought maybe it would be a wifi capacity issue, or a latency issue.
The computer that controls the radio is connected to a small hub that connects via wifi to the fiber optic router, so all traffic works via wifi. I did a basic internet browsing with the same pc and nothing happened, but then I did a speed test and immediately the connection died.
It is curious that from this moment, the wfview udp server stops receiving data, fails to recover the connection, and on the screen still indicates that it is connected to all three ports.
it also does something else curious, if you close it, it doesn’t stop, it does close the graphical interface, but on the console it’s still running. until i got tired (ctrl C) from the console, it didn’t die at all.
I understand then that for some reason when the network slows down the server stops receiving the packets and does not detect that the client has been lost to try to recover the connection.
Certainly my network setup may not be very good, but I have run time with the RSBA1 and have never had this problem. I have long since abandoned windows and finally have another way to do remote without the need for a pc with dedicated windows.
Could it be that you could have more control with the network server? and that he was able to re-establish connections? or at least you detect the drop of the remote info and you don’t keep thinking that the remote is connected.
I leave the log of the moment that failed, in case any information can be provided.
server side
2021-10-18 17:13:11.846 DBG rig: ----- End hex dump -----
2021-10-18 17:13:11.860 DBG default: No more data available but buffer is not full! sentlen: 576 nBytes: 3840
2021-10-18 17:13:11.879 DBG audio: Output Missing audio packet(s) from: 1d7f8 to 1d7f8
2021-10-18 17:13:11.880 DBG default: No more data available but buffer is not full! sentlen: 1152 nBytes: 3840
2021-10-18 17:13:11.892 DBG udp: Missing Seq: size= 55289 firstKey= 1 lastKey= 55290 missing= 1
2021-10-18 17:13:12.092 DBG rig: Final payload in rig commander to be sent to rig:
2021-10-18 17:13:12.092 DBG rig: ---- Begin hex dump -----:
client side
2021-10-18 17:13:11.853 DBG rig: ---- Begin hex dump -----:
2021-10-18 17:13:11.853 DBG rig: "INDEX: 00 01 02 03 04 "
2021-10-18 17:13:11.853 DBG rig: "DATA: 14 02 02 55 fd "
2021-10-18 17:13:11.853 DBG rig: ----- End hex dump -----
2021-10-18 17:13:12.003 DBG default: No more data available but buffer is not full! sentlen: 3840 nBytes: 7680
2021-10-18 17:13:12.011 DBG rig: Final payload in rig commander to be sent to rig:
2021-10-18 17:13:12.011 DBG rig: ---- Begin hex dump -----:
The server should automatically detect that a client has lost connection and disconnect it after around 30 seconds. It is interesting that the server isn’t stopping when you close the window though. The most likely cause is due to a thread blocking and not being able to release for some reason.
I will try to reproduce that issue but it is difficult as I use mainly wired network and don’t see any of these kinds of problems. Once the server has got into this state, it is highly unlikely that you will be able to connect to it until wfview is restarted.
Hi Phil, i have tried to increase the latency and it seems to be getting better, i will have to do more testing and look for an optimal point between more latency and smooth operation.
Hi, I have the same situation as Jordi. I have now upgraded my fiber Connection at home from 100/100 to 250/100 and could run Wfview for 30 minutes without problems. I had VNC running to control my Pi4 and a Dlink Webcam to see the radio. No lost packets 0/1000000, Rx latency 12 ms, rat: 20ms.
To really test I started an Internet speed test via Chromium on the Pi4 that was running Wfview server and then Wfview hung …. I can run terminal and VNC, webcam is Ok but Wfview is hung. I can see via VNC that when I press “Exit program” it lights up but it is not shutting down. An observation the RX and TX Codec widows “opus 1ch” is dimmed. I can kill the program and restart Wfview and then everything is up again. Conclusion: It is a loading problem, Wfview is not surviving when the other programs keep going. / Tommy SM6NZB
This is a very frustrating issue as I just can’t reproduce it. I am using a Pi4 connected to my IC705 by USB as the server and Windows/Mac/Linux PC’s for clients and never see this issue!
I have just tried the same test, running a speedtest in Chromium on the Pi4 server and apart from a bit of audio stuttering on the client (which is to be expected) it recovered fine.
I have pushed some small changes to the server code which once reviewed should make it into master later today so you can try updating your Pi. It is more of a code-tidy but I did notice something that could have affected shutdowns under certain circumstances.
Hi Phil,
I don’t know if you can connect the pi4 via wifi, instead of the ethernet cable I imagine you have now.
I do not have the ability to put the ethernet cable because the radio is very far from the router in my house and I have always made wifi connections.
I have a 300/300 fiber and the wifi only yields me a little less than 100/100, so the bottleneck is the wifi.
I understand that the problem can be observed when 100% of the available flow is filled, and for some reason the server stops receiving data from the wfview cient, or they arrive too late. i think the problem goes in client → server direction, not the other way around, but it’s just a theory.
2021-10-18 17: 13: 11.879 DBG audio: Output Missing audio packet (s) from: 1d7f8 to 1d7f8
2021-10-18 17: 13: 11.880 DBG default: No more data available but buffer is not full! sentlen: 1152 nBytes: 3840
2021-10-18 17:13:11,892 DBG udp: Missing Seq: size = 55289 firstKey = 1 lastKey = 55290 missing = 1
I don’t know where this information is generated, I haven’t been able to study the code well, yet. What it looks like is that it has stopped receiving client data, and lips remain in a “latent” state. once the server wfview is closed, with netstat you can still see ports 50001, 2 and 3 of the udp server activated. and with ps the program is still active.
I have only seen this if communication between server and client has previously been broken. The other times I have closed the server it always closes properly.
When not closed correctly, this line does not appear in the log: 2021-10-21 08: 56: 01.280 INF udp.server: Closing udpServer
If you can’t reproduce the problem, and you want me to look at anything in particular in my setup, you tell me and we do the necessary testing.
Looking through the code, the only possible place that I can think of that would cause the server to crash is if the server is unable to send receive audio and the circular buffer that holds the audio fills-up. I haven’t seen this before but to see if this is what is happening, I have made a change to the audio handling code so rather than waiting for the buffer to become available, it simply returns (it will try again in 20ms anyway!)
This is in my “audio-enhance” branch so you will need to switch to this on your Pi server.
In the wfview source directory, enter:
git checkout audio-enhance
Then build and run wfview in the usual way.
Then run the server in debug mode, if you see “outgoing audio buffer full” messages then this may be the cause and hopefully the server will not then “crash”
Hi Phil, sorry
i have been very busy these days and have not seen your post so far.
I see if I am able to do what you tell me and I try to make it happen.
Hi, I did the compilation of the “audio-enhance” branch on the server and I connected to the client pc where I didn’t touch anything. The client PC is where I usually work about 30 jumps from my house doing traceroute.
In the image you can see the number of packets lost during the speedtest. The good thing is that the connection is not dead and I have already done the test 3 times …
It seems to work.
Maybe SM6NZB can do the same, and see if he also notices the improvement.
Thank you so much Phil, you are a genius!
When I have a moment I try to do some QSO remotely, but I think the modification solves the problem.
Hi. I changed my Pi4 server to a 4GB version and then used the audio/enhanced version on both server and client (Pi400-4GB).
When I start the speed-test Wfview gets som problem, the sound is splattering but it keeps going.
In the log I can see “udpCivData : sending request for multiple missing packets”
Nice work !
