If, like me, you use a Mac and both WSJT-X and JTDX for data modes you may run into a problem I had.<\/p>\n
The problem comes about because both applications insert a property list into \/Library\/LaunchDaemons. These property lists are used by the MacOS to start background processes (or daemons) at system startup. But as far as I can tell there is no defined order in which the daemons are started.<\/p>\n
I installed the SDRplay API which as part of the install puts a property list into\u00a0\/Library\/LaunchDaemons. This must have affected the order in which MacOS started the daemons because suddenly WSJT-X failed to start with a shared memory error. This error persisted even after a re-install and configure of WSJT-X.<\/p>\n
I looked at\u00a0\/Library\/LaunchDaemons because as part of the WSJT-X install you put a property list there. Sure enough, JTDX does the same (as it is derived from WSJT-X) and the property lists clash because (at least on my system and my version of JTDX) JTDX makes the shared memory size smaller than WSJT-X likes.<\/p>\n
So, I think I was getting away with this before I installed the SDRplay API because the WSJT-X property list was being processed after the JTDX one and the shared memory was made big enough for WSJT-X. But after my SDRplay API install the JTDX\u00a0property list was being processed after the WSJT-X one and the shared memory size was too small.<\/p>\n
I fixed this situation by deleting the JTDX property list com.jtdx.sysctl as it is redundant in this circumstance.<\/p>\n
And all is well.<\/p>\n","protected":false},"excerpt":{"rendered":"
If, like me, you use a Mac and both WSJT-X and JTDX for data modes you may run into a problem I had. The problem comes about because both applications insert a property list into \/Library\/LaunchDaemons. These property lists are used by the MacOS to start background processes (or daemons) at system startup. But as … <\/p>\n