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

[Roger Hågensen]

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:

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

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.

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

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?

Could such a feature be snuck into the 2.4.x branch or would it be the 
2.5.x branch?
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).


---
Roger Hågensen,
Freelancer, Norway.