rtl_airband and libshout3 2.4.3

[norbeta]

Hi,

When compiling rtl_airband with libhsout3 2.4.3, rtl_airband cannot connect to icecast server. Strace shows that when connecting to the icecast-server, it gets "-1 EINPROGRESS (Operation now in progress)".
When downgrading libshout3 to 2.4.1, rtl_airband connects to the icecast-server again.

System is running Debian Testing.

[szpajder]

libshout is broken since 2.4.2. See https://gitlab.xiph.org/xiph/icecast-libshout/issues/2315 and https://gitlab.xiph.org/xiph/icecast-libshout/issues/2316 .

[cblknittights]

Ummm.. I am a little stumped and perplexed here...

With out libshout3 then the IceCast functions clearly do not work, correct?

So then I can't connect my setups to my IceCast server..... Ummmm... So ummm... well how can I use rtl_airband to feed audio via IceCast then?

That seems like the basic core function of rtl_airband?????? And what 99% of users are doing feeding to IceCast be it thier own or LiveATC...

Debian Testing and thus *buntus 20.04 will be at 2.4.3.. I just checked my Kubuntu 20.04 testing machine.. 2.4.3... And Raspbian will at some point pull in 2.4.3. as well...

So the only supported path is to build a repo of 2.4.1 libshout3 and libshou3-dev??? So are you going to provide those libs so the software is buildable post 20.04, Debians release, and Raspbian updates beyond 2.4.1.????????? and/or can't use something past 18.04 where its still 2.4.1? ?? ? ?

Ummmm I am clearly missing something here on "WONTFIX" when this would break MAJOR KEY FUNCTION of rtl_airband?

What am I not understanding and/or missing here?????????

[szpajder]

The bug is not in rtl_airband, but in libshout and it has to be fixed there. It will show up basically in every app which acts as an Icecast source using nonblocking libshout API. Even an example application provided with libshout does not work due to this problem.

Debian Testing and thus *buntus 20.04 will be at 2.4.3.. I just checked my Kubuntu 20.04 testing machine.. 2.4.3... And Raspbian will at some point pull in 2.4.3. as well...

Don't let this happen - go to https://bugs.debian.org, file a bug and point them to the two issues on Xiph Gitlab mentioned above. Both can be fixed with a single line of code.

In order to reduce your perplexity factor, I relabel this to invalid. "wontfix" may suggest that I acknowledge that the bug is in rtl_airband and I'm not willing to fix it, which is not the case. In fact, I've already provided a fix - see Xiph Gitlab.

[szpajder]

As libshout is still not fixed, I added a workaround, which is now available in release 3.2.0. It still needs a proper fix on libshout's side - what I see is that it takes about 2.5 seconds to connect to the Icecast server on a LAN, while with libshout <= 2.4.1 it takes only a fraction of a second. But at least it works.

[ScanCaster]

So does this FIX THE ISSUE?????

Per the IceCast ML:

we're happy to announce the release of libshout 2.4.4. The new version
includes several important fixes.

Major changes:
* Fixed handling of blocking/non-blocking mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

• Fixed ICY port
  increment
  • Fixed reusing of handles
  • Fixed error handling of Ogg sync layer * Fixed Passing of errors
    between connection and instance layer.
    Without this fix died connections were not correctly detected.
  • Fixed and improved build scripts

[szpajder]

libshout 2.4.4 fixes issue 2315, but not 2316.

And my workaround for the problem was botched. I fixed this in RTLSDR-Airband 3.2.1.