similar to: where is icecast-kh?

Hi, I hope this is useful for some of you: I'm just finished building unofficial debian packages for icecast2 and libtheora for Sarge (stable). The idea behind this is to keep all the servers which take part on the GISS stream-ring in sync, running the same version of icecast2 kh branch, thus having a common ground for testing and debugging, and stay always on the cutting-edge of

Karl Heyes <karl@xiph.org> writes: > On Mon, 2004-10-18 at 18:27, Jack O'Quin wrote: > > Karl Heyes <karl@xiph.org> writes: > > > > > Are you running with realtime privileges, for this you need to start as > > > root if you want that. Even with realtime privileges there may be odd > > > cases where the scheduling latency is a bit too

On Mon, 2004-10-18 at 21:04, Jack O'Quin wrote: > > > > > > There are several ways to gain realtime privileges. Running as root > > > is the simplest, but perhaps the worst solution. > > > > Just to be clear, with ices, you can drop to a nominated user after the > > realtime scheduler is selected. Running as root after that is not > >

Hi, On 11 June 2013 12:01, Karl Heyes <karl at xiph.org> wrote: > On 11/06/13 07:16, "Thomas B. R?cker" wrote: >> I've had this stream now running for about 1800s and have observed one >> peculiar thing, the cache-fill went constantly down from an initial 20% >> to now about 3%. >> I let it run a bit longer and this is what I get: >> >>

Hi, On 06/10/2013 04:43 PM, Live Mix - Arvy wrote: > Hello Thomas and Karl, thank you for your answer and time. > [?] > We use SAM Broadcaster to encode AAC+ HE 48k. We're using the latest > IceCast KH version, Win32. As I'm neither familiar with the KH version, nor with SAM I won't be of much help. > Other datail: all users have always "Lag: 0" on Admin

Karl Heyes <karl@xiph.org> writes: > Are you running with realtime privileges, for this you need to start as > root if you want that. Even with realtime privileges there may be odd > cases where the scheduling latency is a bit too high, it all depends on > the drivers and kernel version but the current state is not that bad and > getting better. There are several ways to

On 11/06/13 07:16, "Thomas B. R?cker" wrote: > Hi, >> Other datail: all users have always "Lag: 0" on Admin interface > > That doesn't need to be a problem, but without full understanding it's > hard to say. that is just the difference between the latest source offset and client offset, at 0, just like on the main trunk, the listener is at the

Yes, but I'm also unable to read that stream from VLC on OS X and Windows Whamb works on OS X, QCD works on windows. If it is confirmed that VLC is not working with that header, then we may ask VLC team to handle that header ? I downloaded the latest Realplayer, but I'm unable to play my stream... is it really possible? or perhaps it is only for mp3? in that case why not to send that

Hello When I replace ICY 200 by HTTP 200 then : - wget works - videolan VLC works (i thing its bad to send headers that it doesn't understand as it is one of the few crossplateform ogg players) So, I suggest, either to put something in the code to handle a different response header per stream type, or to put something in the config file (but then icecast admin have to bother with that) Or,

On Sun, 2004-12-12 at 21:57, Iceuse - Kris wrote: > Hello, > > I was trying to add metadata to my OGG stream (ices 2,0-kh59, icecast > 2.0-kh51). > It works... but the players are doing a small sound cut at metadata > reception : > - VLC (maybe 1/3sec cut) > - JORBIS (java. maybe 1/10sec, because I can have set higher priority to > sound processing and not to comment

On 06/06/13 17:13, Live Mix - Arvy wrote: > Hi there, > > we use IceCast KH on our webradio, no commercial. We have an issue that > we dont know where to look. When listening using WinAmp (but in other > players too like JW Player), after 70 or 90 minutes, we realize that the > "green square" on top of WinAmp becomes a "red square". About 60 minutes > after

On Wed, 2004-05-26 at 23:15, Iceuse - Kris wrote: > Hello, > > I have some troubles with the latest icecast kh. I'm not sure it an > icecast problem, but I have no idea... > Does someone have an idea about that problem? > > The thing is that icecast is running on a uml linux. But this worked > some weeks ago, then I come back to it, and I can't get it work

On Thu, 2004-05-27 at 19:09, Iceuse - Kris wrote: > Yes, but I'm also unable to read that stream from VLC on OS X and Windows > Whamb works on OS X, QCD works on windows. > > If it is confirmed that VLC is not working with that header, then we may > ask VLC team to handle that header ? if you can verify whether changing the stated line resolves the issue then we'll know

On Friday 28 May 2004 16:20, Iceuse - Kris wrote: > >>Or, keep as it is if it makes sense (I don't know the importance of > >>having or not ICY) and then, see with videloan.org to update their > >> player. > > > >Players should not be changed to support this. They're correct to reject > > it. > > > >Mike > > So, in that case,

On Fri, 2004-05-28 at 07:20, Iceuse - Kris wrote: > >>Or, keep as it is if it makes sense (I don't know the importance of > >>having or not ICY) and then, see with videloan.org to update their player. > >> > >> > > > >Players should not be changed to support this. They're correct to reject it. > > > >Mike > > > >

Simple streaming is fundamentally flawed this way. "The man with two clocks, does not know what time it is." Your source is clocked from one crystal in your source sound card, and played back on the basis of the clock crystal in the client sound card. There is nothing to say or keep these crystals locked to the same exact frequency, which is REQUIRED to maintain no clock drift. Unless

>>Or, keep as it is if it makes sense (I don't know the importance of >>having or not ICY) and then, see with videloan.org to update their player. >> >> > >Players should not be changed to support this. They're correct to reject it. > >Mike > > So, in that case, ICY 200 should be removed? btw, yesterday, after patching it to HTTP/1.0 200, I

Hello Thomas and Karl, thank you for your answer and time. We've tested with several listeners and different connections, using WinAmp and JW Player. For about 15 minutes, everything is ok. After 15-18 minutes, WinAmp starts do blink that "red square" (packet loss or instability), and after about 20 minutes sounds starts to "pop", with small cuts, and then starts to

tobias wrote: > hi, > > i am desperately trying to get this version of ices up and running on debian > etch. i used the apt repository at http://www.fbriere.net/debian/ices2/ but i > found this also affects the "official" source package at > http://mediacast1.com/~karl/ > when i try to run an edited version of either the example file provided with > the

Hi there, we use IceCast KH on our webradio, no commercial. We have an issue that we dont know where to look. When listening using WinAmp (but in other players too like JW Player), after 70 or 90 minutes, we realize that the "green square" on top of WinAmp becomes a "red square". About 60 minutes after start, sometimes the "red square" blinks, and then more