Comment 14 for bug 1329202

If i had a say, no. The patch is most probably not even a solution to the problem.
I think the rather technical description, was decieving.
Of course the URL will, with the patch, will be correctly encoded but nothing is gained with that.

The bug is about Metadata not working, when the mountpoint contains certain characters. (Queryparameters just includes at least one of them, namely the "?")

Current state: Stream is working, but metadata is not working.
Reason is:
The mount name is "/live?stream_id=1&tracking=2". Thats defiend on Connect via the connection whichs stays open for sending audio data.
When updating the metadata an HTTP GET is send via an second connection. The mountname is one of its paramters.
As such icecast unescapes the paramters as its done by any HTTP server. I do not know what the resullt actually is (hard to say what result out of undefined characters for an encoding) but its clear it doesn't equal the mount name. This leads to the request being ignored, as icecast doesn't recognize / cannot find the mount it should update the data on.

State after patch:
A connect and sending audiodata is generally possible, but the mountpoint (resource) will have a different name than expected.
It is something like: "/live%3Fstream_id%3D1%26tracking%3D2"

(actual encoding varys a bit depending on used library)

The name is a) kryptic for endusers b) may cause errors für automatic generated links on the server c) may even prevent a sucessfull connect when the server expects a very specific mount name containing any characters which needs escaping.
But most importantly the metadata still should not work.
The mountparameter can now be unescaped, and will now resolve to "/live?stream_id=1&tracking=2", but a said above thats not the nameof the mount anymore.

If someone could make a testbuild marco-pracucci should be able to verify that.