similar to: Prevent client disconnecting fallen-too-far-behind

On Sat, 2004-11-27 at 21:52, Henk van de Ridder wrote: > Hello, > > Does anybody know how I can configure icecast so it doesn't disconnect a > client which "has fallen too far behind". there isn't anything else icecast can do when that condition is reached > We are using icecast2.01 streaming software for our church home-listening > system. > Our client we

Hello, Anybody got any idea what could be causing this: [2004-04-14 00:15:28] DBUG source/source_main Client has fallen too far behind, removing [2004-04-14 00:15:28] DBUG source/source_main Client removed is this just a bad connection to the icecast server? When I ping the server is get a reply of 20ms and no packet loss. i'm using: -icecast2 -ezstream to create a mp3 stream to the

Hi there, I?m using icecast 2.0.1 with darkice 0.14 streaming an 192kb mp3 stream. Everything seems to work fine except that clients (eg winamp5) disconnect after a period of time (5/10/20 minutes). The icecast log shows some weir errors: [2004-08-18? 01:24:54] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1 [2004-08-18? 01:24:54] DBUG

I am struggling to get icecast running with https, but I cannot get it working My environment is: Debian 10 (Buster) I tried the standard debian package but there is no SSL capability at all. So I compiled the icecast-2.4.4.tar.gz contents with ./configure --with-curl --with-openssl; make; make install I always get the error: [2020-02-05 17:35:36] INFO connection/get_ssl_certificate

Hi All, I attempted to switch my MP3 server from Icecast 1 to Icecast 2 today. I run a Live365 station, Big Planet Radio, which simply relays my local Icecast server. My Icecast 2 error.log file shows a lot of the following messages when the Live365 server, Nanocaster 2.5.6, is connected to it: [2003-05-14 22:09:15] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error

Hi All, I attempted to switch my MP3 server from Icecast 1 to Icecast 2 today. I run a Live365 station, Big Planet Radio, which simply relays my local Icecast server. My Icecast 2 error.log file shows a lot of the following messages when the Live365 server, Nanocaster 2.5.6, is connected to it: [2003-05-14 22:09:15] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error

Hi, I have the following problem with icecast2: I send a stream for some time. Then the source disconnects (maybe just by abruptly dropping the network connection), and I reconnect immediately. My problem is, that these reconnects don't succeed regulary (say, 20-30% of the time). The same setup worked well with icecast 1.x. <p>Akos --- >8 ---- List archives:

Hi guys, i have an Icecast2 server with 3 source client (Oddcast V3). I can see in my error.log this lines: [2005-12-14 12:06:13] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1 [2005-12-14 12:06:13] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1 [2005-12-14 12:06:13] DBUG format-mp3/format_mp3_write_buf_to_client Client had

This may be of help, im tailing the error log file and im getting these errors [2004-04-01 19:14:35] DBUG source/source_main Client added [2004-04-01 19:14:38] DBUG source/source_main Client had unrecoverable error with new data, probably due to client disconnection [2004-04-01 19:14:38] DBUG source/source_main Client removed <p><p>Dave St John Mediacast1 Administration Need

Hello, We are using url authentication and getting the item bellow at the log: [2018-08-24 23:26:05] INFO auth_url/url_add_listener client auth (http://127.0.0.1:8001/listener/add) failed with "" I put try/catch and reviewed all my code ensure always return a proper status and header error code, so what trigger this kind of error? Regards, Thiago --------------

Hi everybody, I'm in charge of an ices2 setup that's broadcasting a local radio station on the Net, and I'm currently under fire because one of our streams has been down twice in two days, forcing me to restart ices2 on each occasion. Our client is understandably unhappy about this. OUR SETUP: I've got ices2 installed on a local machine, broadcasting to an icecast server across

I'm using the latest CVS source under Linux using a playlist of ogg files. When I use a client to connect on the same machine, there is not any disconnect (xmms and zinf). When using a client on a Windows machine, I get mixed results. Zinf on windows will play thru the current song but then stops when the song is finished and does not play the next song being streamed (see log below).

Hi: I have some people who want to be able to broadcast using a shoutcast DSP plugin with MP3, to an icecast2 server. But we can't get it to work. Since I can't be bothered booting one of our boxes into windows to try the shoutcast DSP itself, I decided to use darkice in shoutcast mode. I know this works with shoutcast servers. anyway, it connects, but only briefly, and then is

Thanks for your response Michel. I encode with Omnia AX/E Software so that it can be processed a bit and it has built in MP3 Encoders. I believe it is happening to all my streams, but I only use the mp3 codec. Was encouraged to hear that I wasn’t the only one having an issue and look forward to some trouble shooting thoughts. I do not build my own packages so whatever OpenSSL version is in

Hello Karl In your reply in this case you mentinoned: >> >> Check your TCP buffers sizes as well, a larger RTT (ping) will require a >> larger TCP window to maintain the same maximum bitrate. >> >> karl. We had troubles with the problem of "disconnecting when client has fallen too far behind" and we solved it temporarily by increasing the queue-size and

Hello, We have some problems to use icecast as a Windows Services. We have installed the latest Icecast version in Services mode. We start Icecast. We see an icecast-service running When we connect to the machine, streaming of a MP3-file (by using a M3U playlist) is OK But when we logoff our user, then we cannot get connection to the stream anymore. When we login again, we see icecast is in

Luke Stodola wrote: >Since you want to allow users to connect to any of the three servers, I >don't think you need to deal with "relay-password". Leave your working >server alone, and on the new servers put > > <relay> > <server>serverA </server> > <port>8000</port> > <mount>/foo.ogg</mount>

Hello, We are searching for a possibility of "aliassing without wasting bandwidth". It is described in the following section which we found at http://open4all.info/ossa/_Icecast_Streaming_Server. # What happens is that when a listeners connects to your server and # requests the /laika stream, then your icecast server will connect # as a client to my machine, and then feed my stream to

Ok, I converted my sample .mp3-file to ogg which worked properly. But still no music. I checked the logs and found the folowing: INFO main/main icecast server started (looks good) INFO connection/_handle_source_request Source logging in at mountoint "/example1.ogg" DBUG source/source_main Source creation complete DBUG source/source_main Disconnecting source due to socket read error: