Add an URL parameter to avoid getting ICY metadata #335
Comments
|
*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. |
|
Hello Karl,
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 |
|
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. |
|
Hello Karl, 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 |
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
URL: http://198.51.100.42:8000/stream.mp3
IcyMetadata header: present
ICY metadata are returned
URL: http://198.51.100.42:8000/stream.mp3
IcyMetadata header: absent
ICY metadata are not returned
URL: http://198.51.100.42:8000/stream.mp3?noicy=1
IcyMetadata header: present
ICY metadata are not returned
URL: http://198.51.100.42:8000/stream.mp3?noicy=1
IcyMetadata header: absent
ICY metadata are not returned
This would not break any existing workflow and would solve a huge issue for Google Assistant action developers (which I am).
The text was updated successfully, but these errors were encountered: