Suppress unnecessary rig_init in hamlib.

[tmiw]

Per #172, this only calls rig_init() if the user changes the radio type or on first start.

@drowe67, @Tyrbiter, let me know if this looks okay.

[drowe67]

Looks good to me @tmiw 👍 It would be good to test this change with a wider audience as part of the next beta, PTT has been a tricky area in the past

[tmiw]

I'll generate a new test build tonight containing this and #169. Then if good, we can merge all three pending PRs and generate a final 1.6.1 build.

[tmiw]

Just to confirm, this is with Hamlib/Hamlib#797 applied too, right? If I understood the discussion thread correctly, this PR + that patch should have done the trick (although the VFO will still switch to VFO A on first start, just suppressing it on future starts while the app is open).

Anyway, I'd rather not have FreeDV always keep Hamlib connected as that's a more significant design change.

[tmiw]

BTW, I just emailed out the RC build (based on #168 which contains all current open PRs).

[Tyrbiter]

No, I was using the released hamlib-4.3.1, so I will correct that mistake and report back.

And it turns out that the released hamlib-4.3.1 does have Hamlib/Hamlib#797 included in it, which I wasn't expecting.

I think that this can only work if hamlib isn't reopened, what do you think?

A bit more debugging with verbose on reveals that hamlib.cpp:114 has this:

if(m_rig) {
if (g_verbose) fprintf(stderr, "Closing old hamlib instance!\n");
close();
}

So this closes hamlib whatever happens I think.

I have been trying several things to allow the hamlib-4.3.1 change to work, but whatever happens freedv seems to lose the hamlib instance and that means the Hamlib/Hamlib#797 change is removed from its context.

[Tyrbiter]

I'm with @drowe67 regarding the trickiness of this, so I don't want to hold up the new release and risk breaking this area of the program.

Thinking cap back on...

[tmiw]

I haven't heard of any issues with the test build, so we can probably merge this now.

+ @drowe67