Does this kick CentovaCast's Ass?

[stevewa]

Hi Jay et all.

I'm learning about audio streaming, and came across your site when searching for Open Source stream servers.

If I understand the read me file, this appears to be a competitor to Icecast-KH2 / and Shoutcast

I like your videos showing the use of butt. Since butt is open source i can tweak it's code to fit my needs.

I'm asking if your server collects and stores listener stats so we could generate historical reports like avg listener count over last 30 days? AI have not installed the server yet, but looking at screen caps and playign with RadioToolbox, it appears it is only showing current "active" users?

One of the reasons I'm hating CentovaCast is their metadata seems to suck and it does not generate album cover art inside their contorl panel when recv live audio streams, even when the encoder is sending artist and title metadata. it will only generate album art from live dj mode. Doesn't that seems like some lazy ass excuse? It also appears they are just sitting on their ass and not updating their product. But they sure have their shit spread all over the internet, seems every host uses them.

I also found WHMSonic, but it requires a server that has cpanel installed on it, and a small license fee. they claim they can generate album art, but I have not tried it yet.

But hey, it's only 2016, should we wait a few years before we utilize HTML5?

I can see the promise of the future, the ability to generate additional metadata to be encoded in the stream ( from butt etc), sent to the server, and then passed to the recvr, the player, or on a web page. Most additional metadata would be ignored by normal players like VLC, but on a webpage player, you could use the extra metadata to show dj bio, links, social media urls' etc. Basically an array of data to use as your imagination allows.

I think I read in one of the forums that Jay had some life changing circumstances, I hope things are better now.

Do you have any plans to publicly expose your source code on a site like GitHub so others could help you with it, or are you trying to keep it away from the other companies?

I can envision a better use of listener ip tracking, to show returning users, and why not allow a token in a stream url that would identify the listener as a registered user, and engage them with some goodies for being a loyal listener? Similar how amazon and other sites use cookies to help you keep a list of viewed products, etc.

By the way, anybody know how services like iHeartRadio / TuneIn, etc, can survive on advertising revenue? It doesn't seem like it would generate that much $$$ but I could be wrong. The most aggravating thing about TuneIn is that you need to contact a support person to tell them what information you want updated in your program listing, I guess it's not in their API yet.

Even Icecast-KH seems like it will only accept 2 data fields for metadata, even for Ogg Vorbis, when I view their source code on GitHub

Does anyone use Last.FM api to request jpg images for album cover art?


Anyway, my priority right now is to inquire about the listener history stats.

And to learn how active and often the source code might be updated so I can plan on using the software?

thanks


does anyone have links to radio station websites that have really neat html5 players?

[stevewa]

I just read something Jay wrote on Text Clad and learned he is a stock market trader. What platform & software, who's your broker? NinjaTrader & CQG for futures & options house for equities & futures for me

[Jay]

If I understand the read me file, this appears to be a competitor to Icecast-KH2 / and Shoutcast

Yes, however with a bit of a slant into HTML5.

I'm asking if your server collects and stores listener stats so we could generate historical reports like avg listener count over last 30 days? AI have not installed the server yet, but looking at screen caps and playign with RadioToolbox, it appears it is only showing current "active" users?

Steamcast doesn't take this approach yet but historical data being stored in a future version of Steamcast isn't out of the question.

I can see the promise of the future, the ability to generate additional metadata to be encoded in the stream ( from butt etc), sent to the server, and then passed to the recvr, the player, or on a web page. Most additional metadata would be ignored by normal players like VLC, but on a webpage player, you could use the extra metadata to show dj bio, links, social media urls' etc. Basically an array of data to use as your imagination allows.

Actually with OGG, this is possible today. In terms of MP3 and AAC, we could open up an API to allow the source to send more information.

I think I read in one of the forums that Jay had some life changing circumstances, I hope things are better now.

Things are going well for me, no worries

Do you have any plans to publicly expose your source code on a site like GitHub so others could help you with it, or are you trying to keep it away from the other companies?

Our current stance right now is there is an open source server already in the market (Icecast) and opening up Steamcast does present some challenges in terms of code control.

I can envision a better use of listener ip tracking, to show returning users, and why not allow a token in a stream url that would identify the listener as a registered user, and engage them with some goodies for being a loyal listener? Similar how amazon and other sites use cookies to help you keep a list of viewed products, etc.

This ability is actually already in Steamcast, the problem is that many players will not support it. Browsers do though. So if you use Steamcast today when we add historical stats all that is needed is the logic to do the analytics.

By the way, anybody know how services like iHeartRadio / TuneIn, etc, can survive on advertising revenue? It doesn't seem like it would generate that much $$$ but I could be wrong. The most aggravating thing about TuneIn is that you need to contact a support person to tell them what information you want updated in your program listing, I guess it's not in their API yet.

Can't comment too much here but I can say that TuneIn is an aggregator listing service and they rely completely on manual involvement historically.

Even Icecast-KH seems like it will only accept 2 data fields for metadata, even for Ogg Vorbis, when I view their source code on GitHub

That's a shame because Ogg Voribis is perfectly suited and Steamcast will expose all OGG fields through the json/xml stats sheet.

And to learn how active and often the source code might be updated so I can plan on using the software?

My hope is to have something new soon.

I just read something Jay wrote on Text Clad and learned he is a stock market trader. What platform & software, who's your broker? NinjaTrader & CQG for futures & options house for equities & futures for me

Not really a stock market trader, I just like to speculate on certain players in the market and some of the trends I see and write about them. That blog is largely just an outlet for me to mind dump.

[stevewa]

Thanks for your fast reply & excellent use of quoting.
very refreshing in a world where support sucks more than a Dyson
I'm glad to hear things are going well.

Steamcast doesn't take this approach yet but historical data being stored in a future version of Steamcast isn't out of the question.

If I imagine this correctly, and since I don't know what the logs of SC contain yet, in the future SC would need to collect & write to a flatfile db of some sort, maybe mongoDB, then create an API REST model to query and return an array of data, which could then be displayed in a browser using javascript to present some fancy graphs / charts and a script interface with google maps for geolocation fancy pants.

Actually with OGG, this is possible today.

I can't seem to understand how to make this work with BUTT. I have the source code for BUTT, and when I dig into the Ogg Vorbis c++ files, it appears it only processes metadata of artist & title. But since I have the source code, I can modify it and see if it can handle additional metadata. Question: when the encoder sends the metadata to the server (SC) does the server simply forward it to all requesting clients, and then the client can use javascript to loop thru the array collection to access the entire set of metadata? I found an HTML5 example from JWPlayer, which seems to show this in it's proof of concept. https://developer.jwplayer.com/jw-playe ... -metadata/


it seems my path forward should be:
1. edit / hack BUTT to try to get it to accept & encode additional metadata to send to the server
2. spin up a linux instance and install SteamCast, and see how the BUTT skunkworks is sending metadata
3. repeat until satisifed

4. hack the JWPlayer HTML5 proof of concept and integrate with Last.fm API to get cover art to display in the player.

5. put into production

6. investigate SC log output for any concept of historical listener stats, i.e. even if only parsing & counting ip connection requests
7. write up a proposal for Jay on proof of concepts for historical stats.


Thanks again

[Jay]

Actually with OGG, this is possible today.

I can't seem to understand how to make this work with BUTT. I have the source code for BUTT, and when I dig into the Ogg Vorbis c++ files, it appears it only processes metadata of artist & title. But since I have the source code, I can modify it and see if it can handle additional metadata. Question: when the encoder sends the metadata to the server (SC) does the server simply forward it to all requesting clients, and then the client can use javascript to loop thru the array collection to access the entire set of metadata? I found an HTML5 example from JWPlayer, which seems to show this in it's proof of concept. https://developer.jwplayer.com/jw-playe ... -metadata/

Yes, you may need to add additional entries in the meta data since the encoder may follow the old paradigm of the way Icecast and SHOUTcast used to work. BUTT will need to get the meta data from somewhere and if you have an dj automation system of some kind you can output that meta data to somwhere that BUTT can access (eg database or flat file) to get the communication going.

Steamcast will relay that information on to the client as well as provide it in the stats sheet so you can have your HTML5 player look for those custom entries. I should correct myself and say that technically this works for MP3 and AAC too. The way to get it to work would be to setup a pull encoder and package the additional entries into the ICY meta fields.

A fun little cheat if you want to avoid all this (and this should work for Icecast2 and SHOUTcast as well) is to pack all the additional info an encoded string in the Url field. It's relatively trivial to parse that data client side.

it seems my path forward should be:
1. edit / hack BUTT to try to get it to accept & encode additional metadata to send to the server
2. spin up a linux instance and install SteamCast, and see how the BUTT skunkworks is sending metadata
3. repeat until satisifed

4. hack the JWPlayer HTML5 proof of concept and integrate with Last.fm API to get cover art to display in the player.

5. put into production

6. investigate SC log output for any concept of historical listener stats, i.e. even if only parsing & counting ip connection requests
7. write up a proposal for Jay on proof of concepts for historical stats.

Sounds like a good plan. I will say that at this point, the Steamcast log will not give you any session information yet. IP and User-Agent matching is all we offer right now since all of this is still in PoC for even us. Having said that, I am going to put it in the next build that at bare minimum the w3c log will output cookie hashes it receives so that you can track a listener more closely.

Any other features you would like to see added to make this easier for you, keep them coming.

[stevewa]

A fun little cheat if you want to avoid all this (and this should work for Icecast2 and SHOUTcast as well) is to pack all the additional info an encoded string in the Url field. It's relatively trivial to parse that data client side.

I've tried this before as a GET to an icecast-kh server

/admin/metadata?mount=/live&mode=updinfo&artist=ACDC&song=Back+In+Black&album=Back+In+Black&title=booga&url=pasta.html&artwork=creepy.png

just keep adding on metadata in the Querystring, but the current host I'm using has shitty log updates, so i can't see the result of this call until about 1 hour later, and it does not seem to get pushed into the stream

maybe in the icecast-KH source code I have viewed, it will add all metadata, but only add ARTIST and TITLE keys to the XML stats sheet. it does not seem to process other metadata https://github.com/karlheyes/icecast-kh ... ogg.c#L311

[Jay]

Well in the OGG world things are a bit different since the container is responsible for the meta data The Url meta data substitution would be a solution for mp3 and aac ICY streams and would look something like this:

Code: Select all

/admin/metadata?mount=/live&mode=updinfo&artist=ACDC&song=Back+In+Black&album=Back+In+Black&title=booga&url=page%3Dpasta.html%26artwork%3Dcreepy.png

or

Code: Select all

/admin/metadata?mount=/live&mode=updinfo&artist=ACDC&song=Back+In+Black&album=Back+In+Black&title=booga&url=cGFnZT1wYXN0YS5odG1sJmFydHdvcms9Y3JlZXB5LnBuZw==

Where "cGFnZT1wYXN0YS5odG1sJmFydHdvcms9Y3JlZXB5LnBuZw==" would base64 decode down into "page=pasta.html&artwork=creepy.png"
You can use any delimiter in this example. It just needs to be url safe (no special url characters in the final passed packet) and reversible.

Since you are using OGG, Icecast would have to intervene with that field as well and it doesn't appear to do so in the code you linked. But then this begs the question, why not just encode the page and album cover details in the origin stream? BUTT could do this for you. So long as the meta data gets parsed completely by Icecast to a stats page you could gather it there.

I hate to turn you away from Steamcast but I just don't want you to waste time trying to get it to fit for your needs when your existing solution may just need a tweak.

[stevewa]

Thanks for the thoughts & tips, but it doesn't work.

BUTT can supposedly update metadata by reading the first line of a text file, and manually through it's GUI setting panel, but it never arrives at the server. BUTT's source code does not include a line to log the results of the socket call to the icecast server, so I can't tell where / why it's failing until I hack it, compile & test. I will update my findings later next week.

I can touch Icecast through a web browser and hit the url to update metadata, and it shows up in the icecast access logs,

- admin [15/Sep/2016:14:19:46 -0400] "GET /admin/metadata?mount=/live&mode=updinfo&artist=ACDC&song=Back+In+Black&album=Back+In+Black&title=booga&url=pasta.html HTTP/1.1" 200 208 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36" 0

but the server admin xml file does not use the keys "song" nor "url" so, it seems icecast is ignoring the extra metadata anyway, just as it's source code indicates.

I like banging my head against the wall