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

[Roger Hågensen]

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 http://127.0.0.1:8000/playing-json.xsl?mount=/live
>> 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 
http://127.0.0.1:8000/playing.json?mount=/live

>
>> [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).
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.

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.

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?

Also no metadata (ICY or not) can be reliable. 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.

>
>> 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?
>
> 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.