Wfview crashes continuously running onder MacOS Catalina v10.15.7 (on a Macbook Pro 15 inch (MacBookPro10,1) 8Gb RAM

Happy to provide more info … would you like to use vnc to connect directly to the mac in question ?

Hi John.

Yes that would probably be useful, I am a bit tied-up with “proper” work today but can try to have a look later.

73 Phil

~WRD0001.jpg

iI didn’t mention that I usually operate this mac mini remotely from another mac… long story short … WFView is much more stable WITHOUT my VNC connection to the mac mini running it

Hi John,

I’ve seen this too, it has to do with the waterfall display drawing a lot of pixels every cycle. This action really revs up the compression algorithms and it doesn’t compress that well anyway. If you use TurboVNC server and client, with some tweaks to the quality controls, you can get it working well enough (but not great really).

With the built-in UDP server on the horizon, hopefully running it this way is a thing of the past. You can always turn off the waterfall display to get it more responsive. I see the same issue in fldigi over VNC BTW.

Take care,

–E
de W6EL

I by the way test remotely too, using nomachine nx and it beats vnc there. It’s available for
linux, mac, windows.

I tried the latest (14th May) download today … a few minor things at startup … looked ok until I turned the physical VFO knob on the radio, it looks like the flood of unsolicited CI-V messages crashed Wfv. Incidentally when I use Rs-R8600, it locks out the radio AND lights a White LED on the front panel, so icom avoid the flood too ?

That’s interesting so when using RS-R8600 you can’t use the radio front panel at all?

Hopefully we will have access to an R8600 for testing soon so we should be able to sort issues like this.

Thanks

Phil

Hi John,

That flood of traffic should not crash wfview. I do this test often with my rigs, although I have not done it with the mac build, so maybe that’s something I need to try.

Thanks,

–E
de W6EL

correct … locked out when connected … here is a Video : https://youtu.be/JtjAV_cXG0w

Hi John,

Would the desired behaviour be to not have local control locked out? I think there may be a CI-V command we can send to get that. Reminds me of HP/Agilent/Keysight equipment which do this by default when they receive GPIB traffic.

–E
de W6EL

I’m pretty computer illiterate so I’ll be limited in the info I can give you. I’m running a Late 2013 MBP 13 with macOS 11.4. When I first downloaded Wfview, about a week ago, it was easy to set up and worked surprisingly well. The waterfall was good, all controls I tried, worked. It seemed stable. My radio is an IC-705 and I’m using the WAN “access point” method so the radio is the router. I tried to use soundflower, vb-cable and blackhole to connect wsjt-x to wfview and at first I was kind of successful with vb-cable. I received and decoded fine and I transmitted FT8 and was copied fine but only for short times (30 seconds to 13 minutes) and then the transmitted signal would stutter and I’d switch to a dummy load to play around. Sometimes I could get it back up quickly and sometimes not. I could not find any step by step instructions on how to use any of the virtual audio cables so maybe that was a problem. Do you have any idea on how improper use of the vac could cause the stuttering and eventual stoppage of transmitted audio? I tinkered a great deal with those vac s and eventually wsjt-x started crashing over and over. Now wfview on its own is difficult to connect to the IC-705 wifi and needs frequent reconnection. I’m thinking I might have corrupted the wfview installation. What is the safest way to uninstall it on the mac?

Thank you
fritz

1 Like

For audio piping on mac i use iShowU Audio capture since 10.14 and also now with 11.4. But there seems to be a new version of them called SWB audio app:
swb audio app
iShowU Audio Capture
I had connection problems because on another computer was wfview still running with the same user, but thats probably not your case.
I think deleting the app should do the job. did not find anything in library/ApplicationSupport etc which has to be deleted.

Thank you. I’ll go ahead with a wfview reinstall and look at those audio options.

Fritz

I can confirm that wfview 1.62 was the last version that worked on MacOS Catalina (10.15.7).
Version 1.64 silently crashes. When starting the application inside the .app directly, I get the folowing error message:

Last login: Sun Oct  8 13:18:43 on ttys000
/Applications/wfview_1_64.app/Contents/MacOS/wfview ; exit;
admin@iMac-cpr ~ % /Applications/wfview_1_64.app/Contents/MacOS/wfview ; exit;
Sorry, "wfview" cannot be run on this version of macOS. Qt requires macOS 11.0.0 or later, you have macOS 10.15.7.

[Prozess beendet]

So it seems that on 1.64 they switched to a newer QT version which needs at least macOS 11.0. That’s a shame, as macOS cannot be updated further on my otherwise perfectly working iMac from 2012. Damn Apple…

I assume that you are aware of this patcher to allow running newer MacOS on older Macs?

I successfully run Linux on older mac hardware and find it performs much better. You can use Zorin or Elementary OS distributions to emulate the MacOS user interface. It is not an in-kind substitution for a full MacOS workstation, but improves compatibility with many other projects.

I have a 2011 MacBook pro that is running Ventura installed with Open Core Legacy Patcher. I also had to find a TC wrapper to let me add Wfview to access microphone and other devices as Mac OS was preventing Wfview access. Once I got it sorted, Wfview runs fine as client accessing my Mac mini server running Ventura. The problem is on the Mac side, not the Wfview side. I’ve found this to be true with windows as well. Wfview is usually not the issue though I thought it was…

Great program.

1 Like

The original Poster said: "Wfview crashes continuously running onder MacOS Catalina v10.15.7 (on a Macbook >Pro 15 inch (MacBookPro10,1) 8Gb RAM] "

I also noticed that the original poster hasn’t come back to report what was finally done to solve this problem. Was the problem resolved?

It would seem to me the easiest “fix” might have been be to simply upgrade the computer to whatever current (2021) MacOS version was available at the time and now, it would be Ventura because the MacbookPro 10,1 is “Mid 2017” hardware.

There should be no requirement to use a patch with a Mac this new.

I’m running OpenSuSE Tumbleweed (Linux) on my Mid 2012 MacbookPro and Monterey on my Early 2015 MacBook Pro (also running WFView and FreeDV)

Did I miss something here?

73/Rick

1 Like