Unable to read ICY Metadata interval for CORS

[eshaz]

When making a cross-origin request, the Icy-MetaInt header cannot be read in the response. This forces consumers of ICY metadata to manually determine and hard code the metadata interval, or guess it for a given stream. This is problematic because the metadata interval is unique and user configurable for each stream. Attempting to parse metadata with the incorrect metadata interval will result in no metadata and audio glitches.

To correct this, Icy-MetaInt needs to be added to Access-Control-Expose-Headers. This will enable cross-origin clients to read the metadata interval and be able to parse ICY metadata successfully.

Icy-Metadata was allowed in the request headers, but being able to read the Icy-MetaInt response header was missed in #257

334 Adds all known Icy headers, including Icy-MetaInt, to Access-Control-Allow-Headers so these headers can be read by the client in the response.

[ale-rinaldi]

+1 on this, it's necessary to be able to read ICY metadata on JavaScript and avoid other hacky ways to detect them, such as the usual getting an external file every X seconds

[eshaz]

I released a work-around for this issue in my client side ICY metadata library icecast-metadata-js. It reads the response data and derives the metadata interval based on the position of the first ICY metadata StreamTitle.

Regardless, it's still better to read this information from the header. Searching for metadata works fine for reasonable ICY intervals such as 16000, but it can take a while for some FLAC streams that use 524288. It might be a few seconds for the client to receive enough data before the first metadata update.

[eshaz]

Completed in https://github.com/karlheyes/icecast-kh/commit/9da73c9f952e84b2515661bd6163cc39ddd52626, thanks!