Server: Raspberry Pi 3B± Bullseye
wfview: v1.65
Remote: Windows 10 Pro
wfview: v1.65
Radio: IC7300
Connection: USB
After a number of years, I have lost audio connection from Remote to Server. On Server end I ran PortAudio and alsa-brown… for both TX and RX. I no longer have that option on the server end, which I can access with Windows Remote Desktop. I can control the radio through the Server via Remote Desktop.
Log file: [https://termbin.com/9o6g] (https://termbin.com/9o6g)
This started after a remote reboot of the server (software shutdown, OS shutdown (sudo shutdown) then power-off, then power-on)
Suggestions -
I have had this issue before with the IC7300, unfortunately a complete power-down of the 7300 is the only thing I have found that fixes it. I suspect that the USB Controller within the radio crashes?
Phil,
Removed power (remotely) from the 7300 for 20 minutes. Restored Power to it. Checked the Server end (Raspberry Pi) and the Alsa Brown… sound option still does not appear.
Think I am going to try and remotely reload wfview 1.65 (if still available) on the Server Raspberry Pi and see what happens.
I won’t physically be at the Server location for another two months.
Elliott,
Thanks for the response -
Situation has changed some - as previously stated I had been running PortAudio and the alsa brown… audio codec. then suddenly the alsa-Brown… option disappeared.
After trying Phil’s suggestions to no avail, I updated the OS (still Bullseye) on the Raspberry Pi Server. I then installed v2.03 on the Server (I like the look). While putting in the setting, I found that if PortAudio was chosen, I did not have the option for alsa-brown. However, if I chose QtAudio, I did have the alsa-brown option.
From the Server end -(connecting to the Server with Remote Desktop) I have full control of the radio.
I tried to connect from the remote location with wfview v1.65 and could not connect. Nothing to indicate a connection.
I then installed wfview v2.03 on the remote and attempted to connect to the wfview Server with that. Still no connection. Have rebooted several times, (both client and server) verified IP addresses, user names and passwords and I still have no connection. I have a laptop with wfview v1.65 installed I plan to try that on a different outbound Network to see if that works.
Good product, used it for last three years remotely and never had an issue -
Audio devices will have different names under different audio systems. I can’t tell you exactly what they will be so you’ll have to look carefully. The server log will show some more details about the audio devices.
2025-01-30 14:23:10.398 CRT udp: **** Unable to bind to UDP Control port 50001 Cannot continue! ****
I believe this means something else was using that port. Or perhaps you accidentally had two copies of wfview running at the same time. Are you using the cursed “anydesk” software by chance?
After sending the screenshot, I opened wfview on the remote computer V2.03 and connected immediately with good receive audio. I went to the setting screen, disconnected from the radio (opus 1ch, Qtaudio, went to conect and cannot connect to the Server.
I have gremlins somewhere.
Sorry the information is coming in snippets -
I connected to the Server via Remote Desktop. I found that the wfview program was closed. I restarted wfview, disconnected from the server. On the Remote, I launched wfview v2.03 and low and behold I connected to the Server immediately - again good receive audio.
Well, I suppose that is good news really, despite the gremlins!
If you continue to encounter the issue, check the logs on both server and client side while the connection is failing, maybe we can figure something out.