interesting anomaly after upgrading to new version

I thought the upgrade went to easy. LOL

Here is what I'm up against.

I work a lot of modes,   but now I'm trying to work dxcc and WAS using Jt modes.

I use DXLab suite and have DDuT which normally isn't needed in this quest. (barefoot only)

A qsy initiated by  Commander will result in an instantaneous qsy of Commander, Smart SDR (latest) and WSJT-x.

A qsy initiated by WSJT will result in an instantaneous qsy of Smart SDR (latest) and Commander.

But a qsy initiate by SSDR does not always result In what I asked for. LOL usually it's the frequency that is in error while the mode and filter not changing or changing to something other than what was expected.

SmartSDR will qsy to the correct band occasional but the other two apps, Commander and WSJT-x will switch to someo ther wsjt frequency, usually they both switch to the same frequency, but I've seen it where all 3 elements are displaying different band-frequencies. LOL

as long as I initiate the qsy from WSJT-x, the band, mode and filter will be correctly qsyed and if a qso results, the log is saved with the correct data.

I experienced this to a lesser degree (it only happened occasionally) with the SSDR version 1.

I'm betting it's somethin in my setup. Does anyone experience anything similar to this and if so, have they found a fix.

Again so I make it clear, all qsy attempts by selecting a band-mode from WSJT-x properly result in those settings being changed in SmartSDR, and Commander, and of course the log.

It's not a deal breaker...I just have to remember to watch the log.