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

Fri Mar 3 12:37:40 UTC 2017

Hi, thanks for your e-mail and detailed description.

On 3 Mar 2017, at 12:51, Roger Hågensen wrote:

> While  http://127.0.0.1:8000/status-json.xsl?mount=/live
> is fine for info on the server itself and the current track played 
> it's missing a played history.
>
>
> 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.

>
> {
> "date":"2017-03-03T10:57:20Z",
> "server_name":"Testing Stuff",
> "server_description":"Blah blah blah",
> "history":
> [
> {"date":"2017-03-03T10:52:10Z","artist":"Some artist","title":"Some 
> song (this is the current one)"},
> {"date":"2017-03-03T10:48:10Z","artist":"Some other artist 
> 2","title":"Some Song 2"},
> {"date":"2017-03-03T10:44:10Z","artist":"Artist 3","title":"Song 3"},
> {"date":"2017-03-03T10:40:10Z","artist":"Artist 4","title":"Song 4"},
> {"date":"2017-03-03T10:36:10Z","artist":"Artist 5","title":"Song 5"},
> {"date":"2017-03-03T10:32:10Z","artist":"Artist 6","title":"Song 6"},
> {"date":"2017-03-03T10:28:10Z","artist":"Artist 7","title":"Song 7"},
> {"date":"2017-03-03T10:24:10Z","artist":"Artist 8","title":"Song 8"},
> {"date":"2017-03-03T10:20:10Z","artist":"Artist 9","title":"Song 9"},
> {"date":"2017-03-03T10:16:10Z","artist":"Artist 10","title":"Song 10"}
> ]
> }
>
>
> Now ideally a web player should not directly poll this, a webdesigner 
> would hopefully make a serverside script that fetches this say maybe 
> once each 300 seconds (5 minutes) which should be enough unless the 
> station is a jingles only station in which case a shorter interval is 
> needed to not miss any songs. The script will then cache and provide 
> the cached copy to the web players. This avoids hundreds of (needless) 
> requests to the Icecast servers at the same time. But I'm getting 
> sidetracked here now.

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.

>
> Back to the JSON above, the first "date" is critical, this is the date 
> This info was retrieved/provided and act's as a clock reference for 
> the "date" fields in the song history array. Why a clock reference? 
> Let me digress or a moment. Working on a webplayer myself right now 
> I'm frustrated with Shoutcast v2 providing a nice history of songs but 
> the UTC time is off, I'm assuming the server time is off by N amount 
> of minutes (and I don't control that server), Shoutcast v2's 
> http://127.0.0.1:8000/played?sid=1&type=json does not provide a 
> date/reference clock, nor does Shoutcast v2 even provide a HTTP date 
> header (what the hell?). Luckily I'm able to poke a different (non 
> Shoutcast v2) served page on the same server and get the server date 
> from there so I can't adjust all the times in the history to the 
> correct UTC that the server hosting the script has).
> 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.

>
> With Shoutcast v1 you have the scrape the pages for this info (stream 
> title/description is one url, history is another url, and a third url 
> to try and get server datetime).
> With Shoutcast v2 there is luckily JSON support but it's still 3 urls 
> since, you are just spared having to scrape anything.
>
> 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.

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

>
> Could such a feature be snuck into the 2.4.x branch or would it be the 
> 2.5.x branch?

That is up to Thomas to decide, personally I don't think this can be 
done (properly, at least) for 2.4.x

> All the needed info is there internally, and Icecast just need to 
> "remember" the current + the last 9 (total history of 10 as a 
> default).

Icecast is already able to remember the song history, in 2.5 at least.

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)

>
>
> ---
> Roger Hågensen,
> Freelancer, Norway.
>
> _______________________________________________
> Icecast-dev mailing list
> Icecast-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast-dev