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

[Roger Hågensen]

On 2017-03-03 15:43, Marvin Scholz wrote:
> On 3 Mar 2017, at 14:53, Roger Hågensen wrote:
>
>> In that case I'd like to suggest 
>> http://127.0.0.1:8000/playing.json?mount=/live
>
> 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 
> now.
Ah! Gotcha.
>
>>> 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.
I'll just have to test and maybe peek in source code then.

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

But that would still require some form of authentication?
Right now the station I do tech stuff for ran into a situation where 
"Bose Monitoring Service" showed up as a listener useragent, they are 
basically tuned in to the stream and fetching metadata from shoutcast. 
What they Exactly do with this data I have no idea but they provide it 
to the listening devices user use. This was a issue, not only did they 
take up a listner slot but royalties for all the songs would be charged 
as well since this is a 24/7 listener even if it's not a listener. I 
exchanged a few emails with them and informed them about the JSON stuff 
Shoutcast v2 servers had and how to get the history info. But I had to 
say that there was no way to get the same info from Icecast in a simple 
way that I was aware of.

With authentication you can get more info but why would my station hand 
admin access to Bose? And Bose is not unique in this. Over the years 
when I had to lookup info on retrieving current song/history etc I often 
see someone suggesting parsing the audio stream. And my first though is 
that these must be amateurs that can thing straight. (a simple XML or 
JSON request if gzip compression is applied could fit in a single TCP 
packet or two, compared to a stream)

Basically Bose did a very un-clever thing and consumes almost 1GB of 
data to do what a simple HTTP fetch could do once per 30 minutes, which 
would be barely a blip o the daily bandwidth use), and since they 
probably have thousands of users/devices and there are tens of thousands 
of stations that's a lot of Bose Monitoring Service's running out there. 
Bose responded back and Said they will change the way they fetch this 
info but they can't give any ETA on that.

Which gave me the idea that hey Icecast could provide public history 
info like Shoutcast 2 does, only you know, better. I'm in the process of 
re-designing the webplayer for our station and though two birds one hand 
(or however that expression goes).

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

I'll make doubly sure that my own stream player, as well as a Source 
program I'm making do it the proper way then.
I'm aware of the hack nature of the GET based title update, I once 
experience two source clients (both Shoutcast Source DSPs) where one was 
a Live DJ and the other a playlist source but it bugged out for some 
reason and kept sending title updates even though it wasn't the 
connected stream, causing wrong titles shown for the live DJ, how fun.

I'm assuming just standard Ogg (and similar for WebM) meta sidestream is OK?

>
>> 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.
Ah. I forgot about that, very good point. (I didn't know Icecast cached 
the info, I assumed it generated it live).


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

Thanks. I'll re-think the feature request then reg/submit it later today 
(I certainly will drop the date idea).



-- 
Roger Hågensen,
Freelancer, Norway.