search

karlheyes / icecast-kh

KH branch of icecast
GNU General Public License v2.0
298 stars 107 forks source link

Add an URL parameter to avoid getting ICY metadata #335

Open ale-rinaldi opened 3 years ago

ale-rinaldi commented 3 years ago

Abstract

There are some cases where there is no control over the HTTP headers sent by a client, but only over the URL that is invoked.

One notable example is inserting a media card response in a Google Assistant action: you can specify the URL to be called, but not the headers to send to the server. However, some Android devices feature an implementation issue: they send the "Icy-MetaData" header even if they can't understand the metas in the response, so they add up glitches in playback.
This makes impossible to use a Shoutcast/Icecast stream URL in a media card, if not with some nasty workarounds (like having a reverse proxy that filters out the "Icy-MetaData" header before passing the request to IceCast).

Porposal

Since the URL, in all the mayor cases, is a customizable parameter in clients, my porposal is to add a significant URL parameter (I'd call it "noicy") that makes Icecast not returning any Icy metadata, as if the "Icy-MetaData" header was not present in the request.

Examples

This would not break any existing workflow and would solve a huge issue for Google Assistant action developers (which I am).

karlheyes commented 3 years ago

*sigh, Can you check to see if the problem cases are affected by another aspect, the returning of ICY in the response. You should be able to try that with the ?_hdr=1

I'm just wondering if the presence of ICY instead of HTTP in the response is affecting the response header parsing.

karl.

ale-rinaldi commented 3 years ago

Hello Karl, thanks for pointing me to the _hdr parameter. Unfortunately, I tried various combinations of the options, most notably:

But none of those solved my issue, the output on Assistant app continued to be corrupted. Seems really like an issue related to ICY metadata being requested but not interpreted.

However, I'm now thinking that sticking with the "_hdr" parameter instead of introducing a new one is the cleanest option, so I updated my PR accordingly.

Thanks

karlheyes commented 3 years ago

Is there a useragent that might be useful for checking against for this? or do you think this is just something they will fix in an update, so only a temporary thing is needed

karl.

ale-rinaldi commented 3 years ago

Hello Karl, the user agent for this, on my mobile phone, is:

Mozilla/5.0 (Linux; Android 10; LYA-L09 Build/HUAWEILYA-L09; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/86.0.4240.110 Mobile Safari/537.36 GSA/11.32.8.23.arm64

The first part is related to the phone model; the most significant one is the last one (GSA/), which is generically the Google Search App. While it shoud be safe to filter the metadata on this, my fear is that it's too generic and could break other use cases.

For your second question, I really hope this is just a matter of time before this gets fixed; but it's not a thing that happens on all phones so I suspect it has to do with the vendor implementation (or maybe just with the Android version). I dropped a note to the Actions on Google support about this but I just got a generic answer. I will try to write again and be more specific.

Personally I would not filter on an user agent in this particular case, since the stream URL is not something the end user types in: the action developer embeds it into the action. So the action developer, knowing this, can embed the URL with the right parameter, and the user will have no risk of doing something wrong.

Thanks