Hi!
Just released 2.3.0-216b (just plain test binary for x86_64) to test a unknown property of kenwood rigctld (unknown as I do not have rig to test with). This weird property was reported by Jarmo, OH1MRR.

Some time ago I pull requested to change rig frequency and mode reading command from "fmv" to "fm" as the "v" was causing errors with icom rigs that do not support "get vfo" command vnd the vfo information seems not be used any way in cqrlog.

When cqrlog uses "fm" and rig is Kenwood brand user may change vfo from front panel button and notice that cqrlog still shows the previous vfo's frequency. Not the current one that rig shows at front panel display.

This is because rigctld's kenwood part of program needs user program action to resolve first current vfo so that rigctld can use either FA or FB to kenwood to get current frequency.
Rigctld is clever enough to steal the answer from users "v" question and then use right frequency query command, but it is stupid enough that it can not resolve first current vfo by itself and then ask frequency.

That is why cqrlog had "fmv" but did not use the "v" part fro anything, I think.
But even this has been wrong from beginning. Right query command would be "vmf" or "vfm" because Kenwood needs the current vfo information first.
"fmv" may have produced wrong answer once, but on next polling time it has been corrected if vfo has not been altered meawhile again from front panel by user action.

If we like to remove error with icom, and get Kenwoods work in proper way some kind of rig brand information query must be added to cqrlog source code.

Goes to TODO list.