Support ICY metadata

[saschpe]

Hi,

there are plenty of (closed) issues asking for Shoutcast / ICY support. Since I had the same challenge I came up with an extension. It's in use already but I'd like to know if it makese sense to be mentioned in the extension directory or if there's interest in merging it into ExoPlayer's code-base. I guess it needs more documentation and tests but I'd be curious.

[ojw28]

My understanding is that on some versions of Android DefaultHttpDataSource wont work at all, failing with:

java.net.ProtocolException: Unexpected status line: ICY 200 OK

(here are some relevant issues). This is unfortunately working as intended at the platform level, which is where the failure comes from, because ICY deviates from HTTP protocol. Does your solution do anything to address this issue, or does it just add metadata support where DefaultHttpDataSource works?

I think it's a great idea to provide support, but if we're to do so then I think we need a solution that works correctly across all devices. You might want to do this by implementing a solution that extends OkHttpDataSource instead, since that'll give you consistent behavior across all Android version, meaning that if it works, it'll work everywhere. It also means you'll be using a network stack that's just "better", according to most people.

[saschpe]

Well, OkHttp is quite popular in the Android community but it's also already part ot Android itself, hidden below HttpConnection (AFAIK). On the other hand, it adds a lot of additional size to any APK.
I'm sure things can be implemented on top of OkHttp but I'd rather expect someone with the ICY 200 Ok issue to submit a patch. I don't have a strong opinion though but I just didn't see the need for OkHttp.

This extension is more focussed on really parsing and returning the ICY metadata. At least there is now a place where people could contribute that previously had to be told it's beyond scope for exoplayer.

[ojw28]

As far as the ICY protocol is concerned, I think the ICY 200 OK response is correct. The network stack underneath HttpURLConnection doesn't handle the response on certain versions of Android (if I remember correctly, I think KitKat is affected). This is also working as intended, because the HTTP stack isn't designed to handle the ICY protocol.

So I'm somewhat unclear on where you would expect someone with the ICY 200 issue to submit a patch? If I've understood correctly, the extension you've provided will basically not work for ICY streams on some versions of Android, and I'm not aware of anything you can do at the application level to fix it. Except use a bundled network stack like OkHttp directly, so as to remove the dependency on the network stack under HttpURLConnection.

Please clarify. Thanks!

[saschpe]

What I meant is that the underlying implementation could still be changed given there are some more tests in place. It's nothing I'd do immediately though.

[ojw28]

The underlying implementation of what? Are you suggesting the solution is to patch KitKat devices at the platform level? That's not feasible in practice; many such devices are no longer receiving regular updates from the device OEMs and/or carriers.

[saschpe]

All I can say is that the implementation works for me on API level 19. Different Shoutcast server implementations do different things, the servers I care about work. My point was that if someone needs a library for shoutcast metadata but doesn't get it to work with the server he uses, I'd be more than happy to take patches to port to OkHttp. At the moment I just lack a reason to do it myself.

More importantly, the idea of this issue is to have some list of third-party extensions that might be useful to Exoplayer users.

[ojw28]

I think we're interested in merging this in some form, possibly directly into the existing OkHttp extension as we'd like it to be based on OkHttpDataSource rather than DefaultHttpDataSource.

It's fine if you don't want to spend time making changes yourself, but in order to look at merging we'd need you to contribute the extension in its current form by opening a pull request to our dev-v2 branch, and signing the corresponding CLA as described here. Please do that if you're able to do so, and we'll take a more detailed look at the best way to merge it. Thanks!

[saschpe]

Sorry for the delay. I'll look into it.

[chriscoderdr]

Any update into this?