[Icecast-dev] Icecast status-json.xsl improvements

Marvin Scholz epirat07 at gmail.com
Fri Mar 3 14:43:23 UTC 2017

On 3 Mar 2017, at 14:53, Roger H├ągensen wrote:

> On 2017-03-03 13:37, Marvin Scholz wrote:
>>> I'd like to suggest adding history to status-json.xsl or to reduce 
>>> the size of the json to the bare minimum that a Web base mediaplayer 
>>> might need
>>> Add a new one at
>>> Which will only hold the current info:
>> Right now I personally don't think there should be more .xsl json 
>> things be added, as it's just a transform from XML to JSON and
>> has proven to sometimes cause some weird bugs with malformed json in 
>> the past, so proper JSON generation capabilities in Icecast
>> would be preferred.
> In that case I'd like to suggest 

Well that's not really the relevant thing that I was trying to say, the 
problem is that Icecast currently has no way to natively generate JSON
and adding this is not trivial, given that all internals use XML right 

>>> [example]...
>> More suitable would it be, to use the STATS streaming API that 
>> Icecast offers, server side, and then use a websocket connection to 
>> update the players.
> Um. Where is this documented? I took a look at 
> http://icecast.org/docs/icecast-trunk/server_stats/ but can't find it 
> (I'm probably looking in the wrong place, and if this is supported in 
> Icecast 2.4 then shame on me for not knowing).

This is supported since a very long time, but not documented in a good 
way anywhere, unfortunately. And the output format of STATS is a bit 
weird too.

> And does that require authentication? Since (in my case) the caching 
> of the info for the webplayer(s) is done using a plain PHP script I'd 
> rater not plop password/credentials in it.

Yes, right now it still does, for 2.5 it was planned to allow different 
auth just for STATS, so that no admin credentials would be required for 

> Also websockets are not the best choice for PHP scripts etc. The way 
> it all works is like this:
> The webplayer requests the url (PHP script) and get back the JSON 
> data. However the script will do one of two things, if the cache is 
> not stale it will provide the cached JSON data, if he cache is still 
> it will request it from the streaming server (Icecast/Shoutcast etc), 
> there is some delay while this occurs but the next webplayer will get 
> the cached JSON instead.

I agree that websockets is not really easy to do with PHP.

> This solution works great on most hosting systems.
> Websocket would require a always running service. The benefit there 
> obviously is that the service would generate the json file and the 
> webserver (or possibly a CDN) would just server a static JSON file 
> with no script overhead.
> But PHP scripts can not normally run continuously/never ending (in 
> theory they can but no webservers allow that normally).
> I'm certainly interested in learning more about STATS streaming API 
> (it's news to me).
>>> The server_name and server_description is included since those could 
>>> change between DJs (and are nice to display in the webplayer to the 
>>> listener).
>>> The date for each song is somewhat useful for a webplayer, not only 
>>> can a webplayer show the start time for each song to the listener 
>>> but (with the exeception of the current song) it can calculate and 
>>> show the duration of songs.
>> While this in theory works, it requires that you do _not_ use ICY 
>> metadata (which is used for MP3 and AAC), as ICY metadata can't be 
>> very accurate,
>> due to the way ICY works.
> Not sure why you are mentioning ICY data? The source sends a title 
> update to the stream server, the script (or webplayer) fetches the 
> json data fro the stream server. Not sure how the Shoutcast protocol 
> is involved with this?

Because "The source sends a title update to the stream server" is not 
how things should be done, usually. This is a "hack" for MP3 and AAC, 
introduced for the ICY protocol to work.

> Also no metadata (ICY or not) can be reliable.

With Ogg it can be very reliable, at least timing-wise. Everything else 
depends on correct metadata of the source files, of course.

> For example the station I'm the tech guy at has live playlist and live 
> DJs. The accuracy of titles is beholden to whatever source client is 
> used. Also, it is possible that such is time delayed on purpose to 
> mess wit stream rippers so it will obviously not accurate to the 
> second. But for displaying to a listener as long as it's not more than 
> half a minute off is OK enough, the test setup I have here is accurate 
> to within a few seconds which makes calculating a duration in the 
> webplayer actually useful.
>>> With Icecast there is luckily no need to get a server datetime from 
>>> anywhere else as Icecast has proper HTTP headers, but providing the 
>>> date in the JSON would be easier to code in a script/webplayer, HTTP 
>>> headers can be a bit fiddly, although with a server side script PHP 
>>> or something else should have no issues handling the HTTP Date 
>>> value, but still providing the date in the json simplifies the 
>>> implementation (no parsing needed, just passthrough and cache 
>>> basically).
>> Using the Date headers is the right thing to do.
> But it requires some fiddling around with date reformatting from HTTP 
> date to the one shown in the example JSON, if Icecast provided the 
> server date in it's JSON then that is one less piece of code needed in 
> the script/webplayers. There also seems to be some issues with getting 
> the Date header when doing XHR in javascript (possibly CORS related). 
> Again, it sounds lazy but having less "end programmer" coded needed 
> would be a plus.

Just because something requires more code because Javascript XHR is 
crap, I don't see that as reason why we should include the Date in the 
JSON, that would make caching the JSON impossible for Icecast.

>>> I believe the lack of a song history has been pointed out before, 
>>> now with Webplayers possible (which do not support in-stream 
>>> metadata "out-of-the-box") this is very useful. If Shoutcast v2 had 
>>> a proper server date provided it would still be two calls (to get 
>>> the history and the stream name/description). Icecast can easily do 
>>> this better, right?

It's of course possible to include the stream name/desc in the JSON, 

>> When streaming in modern formats, like Ogg or WebM, browser players 
>> should support metadata.
> I need to look into that deeper (for webplayers) then, I'm currently 
> working on adding Ogg (and possibly WebM) metadata support for a 
> Windows based player I'm maintaining so if browsers can provide that 
> info to javascript then that is awesome.
> BTW! Does this require CORS or is the metadata available without CORS?
>> Could you maybe register at trac.xiph.org and create a feature 
>> request there with the information you included in this E-mail?
>> (If you do, don't forget to choose Icecast as the component)
> Sure, once you answer this email and clarify/answer some of my 
> questions I'll re-think my feature request if needed and then create 
> it.
> -- 
> Roger H├ągensen,
> Freelancer, Norway.
> _______________________________________________
> Icecast-dev mailing list
> Icecast-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast-dev

More information about the Icecast-dev mailing list