using -n including rtlsdr_wsprd won't exit

[Rilapy]

I am using 7e3070a39f31816b75568cc114875905385d1529

When using the -n option rtlsdr_wsrpd does not exit after the specified number of cycles. The main loop does exit but the program gets hung up waiting for pthread_join(decState.thread, NULL);

The decoder() function uses rx_state.exit_flag in it's while loop. Without that flag being set to true the loop keeps going so decoder() never returns and the main thread waits for a pthread_join which never happens. In my local copy I set rx_state.exit_flag = true after the main loop exits. With that flag set decoder() can return.

Once decoder() returns that join happens and the programs can exit.

This leads me to a problem I am having with the if/break at the start of the decoder() function.

static void *decoder(void *arg) {
    int32_t n_results = 0;

    while (!rx_state.exit_flag) {
        safe_cond_wait(&decState.ready_cond, &decState.ready_mutex);

        if (rx_state.exit_flag)
            break;  /* Abort case, final sig */

At the end of rtlsdr_wspr.c if rx_state.exit_flag is set between the end of the main loop and the safe_cond_signal() then that if/break exists the decoder before the last cycle is decoded and spotted wasting the last couple of minutes. If rx_state.exit_flag is set between safe_cond_signal() and the pthread_join() then by the time rx_state.exit_flag is set that if/break has already been skipped and has no effect.

That is the behaviour I have been finding. I do not want that if/break exiting decoder() so I removed it in my local copy as I want the decode and spot before the program exits. If there is a better spot to set the exit_flag so decoder() returns I am happy to test.

if I want 1 decode cycle then I would set -n 2 and the expected behaviour for me is a decode and spot before exiting the program.

[Guenael]

@Rilapy I will take a look, thanks for this bug report.

[Guenael]

@Rilapy I fixed it in this MR: https://github.com/Guenael/rtlsdr-wsprd/pull/124/files The latest version should work, LMK.

Note: You have to start your RX before the new minute starts, otherwise, you will lose a cycle, but your TX is shorter than 120 sec anyway, it should not be a problem.

[Rilapy]

After your comment about 19 hours ago it has been exiting cleanly for me.

An update you did since then looks like rtls_wsprd has stopped counting the initial wait as a cycle. That gets rid of the confusion of -n 1 exiting before starting a decode cycle. In the last hour -n 1 or -n 2 or -n 3 have been reliably giving me 1 or 2 or 3 decode cycles instead of the old behavior of 0 or 1 or 2 respectively.

To me this is now working as expected. Thanks.

[Guenael]

Yep, now if the first RX is incomplete, it will not count it as a cycle.