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