Could liq stream using TLS to icecast since it does now support it, and (it seems, for 2.4.x at least) libshout as well?

The tarball attached to the 0.6.3 release is named ocaml-cry-0.6.2.tar.gz rather than ocaml-cry-0.6.3.tar.gz (I didn't check its contents).

Thanks.

Addressed in #9 but this would be useful icecast instances behind reverse proxies that route based on Host header and may serve different TLS certs based on SNI.

After upgrading from 2.0.2 to 2.0.3 I noticed that my dynamic metadata wasn't updated anymore. After some investigation I was able to pinpoint it to the icy.update_metadata call that apparently is broken in 2.0.3. After switching liquidsoap back to 2.0.2 again it worked without a problem.

Testscript:

radio = input.harbor("radio", id="radio", port=1234, user="source", password="hackme", buffer=5., max=20.,replay_metadata=false)

m = [("title", "This is - a test"),("url","http://google.com/image.png")]
icy.update_metadata(mount="/mystream",password="dummy",host="localhost",port=8000,m)

output.icecast(
  %mp3(bitrate=128, stereo=true,samplerate=44100,internal_quality=3),
  host="127.0.0.1",
  port=8000,
  public=false,
  fallible = true,
 description="My stream",
 mount="/mystream",
 icy_metadata="true",
 password = "dummy",
 url = "https://www.mystream.net",
 name = "Just listen",
 genre = "Pop",
 radio)

You'd expect that after running the stream has "This is - a test" as title metadata, it does this in 2.0.2 and previous versions, but not in 2.0.3

• OS: Ubuntu 20.04 LTS (Focal)
• Version: 2.0.3 (pre-compiled deb from github)

As mentionned in savonet/liquidsoap#1425 ocaml-cry seems to be misbehaving when it comes to IPv6.

Using an explicit IPv6, this happens, as if it was trying to resolve it… great.

2022/01/18 23:29:49 [ice:3] Connecting mount test for source@2001:41d0:d:2147::106...                              
2022/01/18 23:29:49 [ice:2] Connection failed: Not_found                                                               
2022/01/18 23:29:49 [ice:3] Will try again in 3.00 sec.

If the name is ipv4/ipv6 resolvable it ignores the IPv6, which is … not what is supposed to happen.

I can provide an IPv6 reachable client/server if it helps.

I'm vaguely guessing something in connect or in unix_transport is fishy, but I'm reaaaally not good at OCAML :P