From G8GKU, installed V2.1 on Win 11 machine. AMD processor. Wfview runs via WiFi and router. I have noted that selecting " Disconnect from Radio ", does so and about 4 seconds later WFview terminates. Well done re all the work. 73 John
G8GKU/JohnW,
You say Disconnect causes wfview to terminate, do you mean that wfview crashes? Disconnect should allow wfview to remain open. Just checking.
Thanks,
âE
de W6EL
To add to Elliottâs question, do you have anything else sharing the connection like virtual serial ports or rigctld, as I did have an issue previously that would cause a crash on disconnect when a rigctl client was still requesting data, that was fixed in 2.01 though.
Hello Elliot. When WFview is happily running the radio, an IC-9700, if the Disconnect from Radio button is clicked, then the link to the radio is closed, as expected. Then about 4 seconds later WFview closes and correctly restarts when WFview icon is clicked on the desktop. I am unsure if it is a crash or a close-down. I have not got as far as " End programme ". John
Hi, from G8GKU. The 9700 is the only device or service in the system.
Hi G8GKU/JohnW,
Yeah it is not supposed to close the program a few second later. That likely is some kind of crash. But Iâm glad the rest of it is working for you. We may follow up with you with a request for a log file showing the crash.
âE
de W6EL
You are most welcome. John
Elliot, Phil,
I was not sure, what to do with âclear out that VirtualSerialPort textâ. Delete the whole entry or only the text? So I decided to revert my changes and go back to the original wfview.config.
After the update, the shown entry in the settings menu was correct (/home/pi/rig-pty1), however, it did not work. So I checked the config file, where the entry was still âVirtualSerialPort=ManualâŚâ. Then I went back to the settings, selected the virtual port again and restarted wfview. Now it works as expected 
The entries are ok as well.
Btw.: while looking at the config I found all the âoldâ memory entries. Arenât they now obsolete and could be deleted?
Thomas, DL3EL
Hi DL3EL/Thomas,
You can delete the entire line or just zap the part after the â=â. Either would reset the setting. Looks like you got past that though.
The memories in the config file can still be used via the Frequency entry window (STO and RCL). And if you remove them, theyâll get put back each time you save settings. So, for now, Iâd just leave them alone. Perhaps we will remove that function in a future release.
The Memory editor that Phil wrote is truly superior and supports more features, so I would just use that for any memory operations. It also supports CSV files.
âE
de W6EL
Just want to confirm, that Phils memory editor is really great and a big enhancement to the system. After looking a bit into the CSV, it was quite easy to convert my IC7610 memory-file into a IC7300 memory-file.
Thanks for all your work.
Thomas, DL3EL
1 Like
Did you install the OpenSSL libraries as directed by the WSJT-X User Guide?
this is happening to our IC7100 also. Server on Debian 12, clients on Windows 10 - no audio from the client to the server is working, so not possible to TX any audio, and audio from server to client is only working sometimes.
swapping back to the 1.6x binary on the server restores audio instantly.
I went ahead and installed it (never needed it before). Still not functioning. Error showed up when i clicked âUpdate Hamlibâ. Worked perfectly with prior version.
It is a pre-release version for a reason 
you are probably best to go back to the stable version.
there was tip from Phil earlier today: on V2 with Deb12, just reselect the devices (even if they already show the correct values). Worked here instantly.
Thomas DL3EL
Yes, it immediately crashes, Iâm using the IC-705.
Looks like it crashes on QThread:
Thread 18 Crashed:: QThread
0 libsystem_kernel.dylib 0x19716a600 __pthread_kill + 8
1 libsystem_pthread.dylib 0x1971a2f70 pthread_kill + 288
2 libsystem_c.dylib 0x1970af908 abort + 128
3 libsystem_malloc.dylib 0x196fb9524 malloc_vreport + 896
4 libsystem_malloc.dylib 0x196fe14a8 malloc_zone_error + 100
5 libsystem_malloc.dylib 0x196fc5ec8 free_list_checksum_botch + 40
6 libsystem_malloc.dylib 0x196fb26e0 small_free_list_remove_ptr_no_clear + 960
7 libsystem_malloc.dylib 0x196fadc48 small_malloc_from_free_list + 528
8 libsystem_malloc.dylib 0x196fad360 small_malloc_should_clear + 196
9 libsystem_malloc.dylib 0x196fad190 szone_malloc_should_clear + 124
10 QtCore 0x1079c20b0 QArrayData::allocate1(QArrayData**, long long, QArrayData::AllocationOption) + 124
11 QtCore 0x107960674 QByteArray::QByteArray(char const*, long long) + 92
12 wfview 0x104d1bde0 audioHandler::getNextAudioChunk() + 252
13 QtCore 0x1079081b8 0x107824000 + 934328
14 QtCore 0x1078fff64 QObject::event(QEvent*) + 644
15 QtWidgets 0x1065270c0 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 336
16 QtWidgets 0x10652807c QApplication::notify(QObject*, QEvent*) + 504
17 QtCore 0x1078b7bdc QCoreApplication::notifyInternal2(QObject*, QEvent*) + 212
18 QtCore 0x1078b9594 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 2316
19 QtCore 0x107a420bc QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 84
20 QtCore 0x1078c2d3c QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 1112
21 QtCore 0x1079a9bb8 QThread::exec() + 332
22 QtCore 0x107a40170 0x107824000 + 2212208
23 libsystem_pthread.dylib 0x1971a32e4 _pthread_start + 136
24 libsystem_pthread.dylib 0x19719e0fc thread_start + 8
Do you like me to send the problem report?
Hi PA3BYA/Gerrit,
Did you manage to get through the initial setup? Or were you using prior-stored settings? Or does it crash before you can do the initial setup?
âE
de W6EL
Unfortunately, everything that uses the Qt framework (like wfview) will crash on QThread!
I can see audioHandler::getNextAudioChunk() is mentioned, so I assume you are actually connected to the radio when it crashes (albeit briefly). Can you start wfview with the radio switched-off and just double-check the settings.
I would pay particular attention to audio devices. Make sure they are correct, and if using a different audio system, select âQt Audioâ as that should be the most compatible.
Phil / Elliott:
In response to Wfview crashing with a disconnected radio, I tried various ways to get it to crash or stop responding and could get it to stop executing ONLY by first removing the underlying USB enumerated CAT port.
Environment,
W11 Pro, 23H2, IC-7300, Using VSPE 1.5 to create a virtual splitter port for IC7300 USB CAT port to support Wfview, MARS software, ION2g, and other software.
What I have found is:
On the server side (Latest 2.01 marked release), with the radio disconnected, Iâve tried to load memories, transmit, bands, etc. My wfview has not crashed but simply waits for the 7300 to be reconnected without crashing. Upon reconnect, the process simply continues as normal.
I then moved to the Remote Client side (Prior 2.01 release marked 2.0) and repeated the same tests, trying server disconnected, remote connected, server connected, remote disconnected. Again, except for 1 time which I cannot get to repeat, the server stayed operational and the remote simply waited for the server side to come back on line. The one failure was clicking on the Freq button and the server side died once after 4 or 5 seconds but the remote client stayed operational.
I then told the server Wfview to power off the radio and still no crashes. It wasnât until I physically removed the underlying VPSE virtual port by disabling the VSPE service, did the server Wfview stop executing. However, the remote stayed up without crashing. Once I returned the server to operational service, the remote immediately started processing audio packets.
Seems to me various underlying O/S or QT implementations on that O/S effect the softwareâs response to removing or de-enumerating the underlying CAT port, which is NOT an unexpected response to that scenario. It is interesting to note that the Eterlogicâs new 1.5.x VSPE is now a service and continues to provide a virtual shared CAT port even though the radio is physically powered off. It still presents the virtual CAT port to the software in spite of the underlying real physical 7300 port being de-enumerated or 7300 powered off.
As to your software, it seems to simply wait for the server to come back on line or one cancels the operation, like recall memories, freqs, etc.
Well done! Your software (at least under W11), IMHO, is properly operating given that the underlying hardware has been ripped away.
Don R. Jarvis
W5SOG
1 Like