welle-cli: Retuning to a channel that was already used results in no playable services

[lorddevereux]

First off, just discovered this project and love it a lot.

I am using welle-cli via another front-end app, so bypassing the web interface. I have had an issue where tuning to a channel which has been used before by that cli instance will result in the mp3 files all being unplayable.

For clarity am running the server using the following, to decode all services
welle-cli -Dw 8000

To reproduce this problem, I do

• start cli, tune to 12B, all mp3 channels working properly
• tune to 11B and back to 12B, and all mp3 channels no longer work. Trying to load them via the browser the http request just hangs

I managed to isolate the problem, in that "programmes_being_decoded" is not being properly cleared when the channel is switched away from in the first place. This means when you switch back to the channel, the programmes don't start being decoded again (although the MUX information from the json file seems to be updated)

To prove this was the problem, I added:
programmes_being_decoded.clear();

to the code block
cerr << "TEARDOWN Cancel all PHs and remove services" << endl;

in webradiointerface.cpp
void WebRadioInterface::handle_phs()

I am very new to this project and rtl-sdr in general, so I didn't want to propose this as a patch until someone who knows the codebase better can be sure there would be no unintended consequences, or if there is a mechanism elsewhere in the code that should do this, but isn't working properly.

For example, this is possibly a better solution
const auto srv = rx->getService(ph.first);
if (srv.serviceId != 0) {
(void)rx->removeServiceToDecode(srv);
programmes_being_decoded[srv.serviceId] = 0;
}

[mpbraendli]

Hi, thanks for your report! I can't guarantee I can look into it anytime soon. Please continue testing and if you feel that your change makes it more robust, please do a pull request.