similar to: Character encodings in ICY metadata

UTF-8 is now the universal standard. It supports ALL character sets. /greg. StreamS HiFi From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Fred Gleason Sent: Saturday, December 01, 2018 15:14 To: Icecast streaming server user discussions Subject: [Icecast] Character encodings in ICY metadata Available Attachments * Untitled attachment 00015.txt

Good morning, On Sat, 2018-12-01 at 16:20 -0800, Greg Ogonowski wrote: > UTF-8 is now the universal standard. (ICY context:) Expect if you are in Asia. Or in central Europe. Or maybe in Africa. I'm not aware of servers on the poles, maybe they use..., ... > It supports ALL character sets. As long as "ALL" is defined as what English people need plus all emoji in all skin

Hi... Can someone do me the favour of pointing us at a routine, library, script or technique that will grab Now Playing metadata (Title, Artist, Album) remotely (ie from another machine) from an Icecast 2.4.x server reliably for logging purposes, preferably using PHP? Ideally we would grab the metadata when it changes - all the methods we've tried so far require us to poll the server so

Hi, Fred... Many thanks for the suggestion! If we simply want to output metadata as you describe, how much,if any, of the prerequisites described in https://github.com/RadioFreeAsia/GlassPlayer/blob/master/INSTALL can we dispense with? We are dealing with a shared hosting system for the host so installing the bare minimum would be a good idea (especially as we may have to ask the provider to

On Oct 21, 2018, at 12:05, Jordan Erickson <jordan at coolmic.net> wrote: > 283000/5000=56.6 > > So with ~283Mb/s upstream, if you wanted 5,000 listener capacity your > streams would have to have a bitrate of 56.6kb/s or lower. Speaking conservatively, I would de-rate that number by 50%, or in other words: 0.5*283000/5000=28.3 kb/sec. This to account for various overheads

Couldn't you also just have a client stream locally from icecast that can do things on metadata change? I mean it's a bit icky but it'd work. ---- Philipp Schafft wrote ---- >Good morning, > >On Thu, 2018-11-08 at 12:45 -0500, Alex Hackney wrote: >> I actually got this to work this morning finally. The problem was on my >> auth server. > >Perfect. :) >

Dear support Can we use this software to listen the music that's coming from Icast and Museter server and if we have a silent issue on the stream can this software automatic move to backup station? [cid:image001.jpg at 01D4DFE8.15F65960] Abdallah Al-Sabateen Technical support t :+96265638000 Ext 8110 f :+96265638029 Email:abdallah.alsabateen at seagulls.com -------------- next part

Hi Fred. Appreciate your response. Maybe in my explanation I have some red and green apples, but I can agree that my understanding is as you explained it. 😊 The point is that if I can successfully stream mp4 with H.264 and AAC encoding without any issues to icecast, I can then use ffmpeg to turn it into HLS which then solves my iOS support issue. The CPU cost of repackaging MP4 into HLS

Howdy Folks: Is there a way in v2.4.2 to include a ?StreamUrl=? field in the stream metadata as well as ?StreamTitle=?? It appears that the administrative interface only populates StreamTitle. For example: http://server.example.com:8000/admin/metadata?mount=MyMount&mode=updinfo&song=MySong will insert only ?StreamTitle=MySong?;. Googling around has brought up some possible

On Jan 27, 2020, at 08:21, Rondejavu <rondejavu at gmail.com> wrote: > I was hoping that had changed. I read something about the copyright expiration on the MP3 format that could affected it’s use in Ices. MPEG-1 Layer III (popularly known as ‘MP3’) has been patent clear since 16 April 2017. One other live encoder option that supports both OggVorbis and OggVorbis as well as MP3 is

On Mar 21, 2024, at 9:02?AM, gARetH baBB <hick.icecast at gink.org> wrote: > Or you could just use ffmpeg: Since we?re discussing HLS encoder options, there is also: https://github.com/ElvishArtisan/GlassCoder Which does not require LiquidSoap, ffmpeg or even Icecast. Just aim it at a web server or CDN publishing point. Cheers!

On Feb 14, 2023, at 13:24, HGAlt <hgalt at gmx.net> wrote: > I am a little bit confused! > > http://192.168.1.10:8000/admin/killclient?mount=/mystream.ogg&id=21 <http://192.168.1.10:8000/admin/killclient?mount=/mystream.ogg&id=21> > > This is an example of the Icecast documentation for kill a client. > And this is a HTTP GET, which is send to the Icecast

Thnaks for your replay I hade installed GlassPlayer but a can't see where can I add backup stream or silent alarm Can you help on this please, please see the attached -----Original Message----- From: Icecast <icecast-bounces at xiph.org> On Behalf Of Fred Gleason Sent: Thursday, March 21, 2019 7:06 PM To: Icecast streaming server user discussions <icecast at xiph.org>

Hi Fred, I am understand the requirements already a little bit better. What I have to Do is a HTTP GET with a Basic Authorization in the header. I have tested it with 'Postman' and it works fine with Icecast. But I have to do it with Javascript or JQuery. Therefore curl doesn't help me. I try to use Ajax for that, but something goes wrong. If I do it without Autorization, I got

Good afternoon, On Sat, 2019-05-04 at 10:19 -0400, Fred Gleason wrote: > On Fri, 2019-05-03 at 12:24 -0400, Fred Gleason wrote: > > > Don't use PUT at all. Instead, open a TCP socket connection to the > port > > that the server is running on, write all of your headers to that > > (terminating each one with a CR/LF), send a naked CR/LF to tell > Icecast >

Tom and Frederick. Thank you both for your input. It is greatly appreciated, not only by me, but I am sure for many others who find this thread. Tom - using Linux server for icecast. HLS was brought to my attention a while back on the liquidsoap forum. I have not had a chance to completely look in on it, but do plan on checking it out. Tom. You have your icecast servers in a round robin

Hello, I have a request for an additional header. This header is needed to inform the client of the burst it is going to receive. Why ? This header could be very usefull for the streaming-client to have an idea of it's delay, and (much more important) to be able to do early-on streaming. The question is not on how to implement this in code (probably send the header in the

On Mar 20, 2024, at 13:16, Wayne Barron <wayne at cffcs.com> wrote: > In Windows and Linux web servers, we can create a forest for our web servers. > Send traffic to different servers to even the workload. > > Can we do something like this with the Icecast servers? > (or) > Will we have to install new VMs, add the heavy stations on that one, > and send the new traffic

Hi there Thanks Thomas. I was hoping to avoid remuxing as my objective is to run an extremely lightweight server. Just tested and the CPU runs between 9% and 23% for a lecture of 90 minutes - took 18sec. Yes it's a lightweight server, but like I said, that's the objective, and quite a nice challenge :-) CPU = cost and if you have to remux for 1000 clients in a day, integrity of live

Hi all: I'm looking at some of the features in SVN Icecast, particularly the ability to reclaim fallbacks. This feature would be very useful for a project I work with, and could see us switching to icecast from Shoutcast compatible technology. One problem arises, however. Some of our broadcasters use the legacy Shoutcast DSP plugin, which can only perform ICY-style connects. My problem