search for: send_to_listener

...m.HttpDataSource$InvalidResponseCodeExc eption: Response code: 401 So, after 12h trying to reproduce the error we saw what's happening. If the listener connection buffer due to anything, Icecast remove it's connection and log the item bellow: [2018-05-22 23:17:24] INFO source/send_to_listener Client 220977 (xxx.xxx.xxx.xxx) has fallen too far behind, removing My question is: Why Icecast need to do this? Why the client can't reconnect? The error 401 is when the client tries to reconnect and our auth deny? Best, Thiago -------------- next part -------------- An HT...

Hi, I've a little bit trouble. I've set up an icecast 2.2.0 and an ices 0.4 system. Every song, sometimes every two songs my playler lost the connection to the stream and in DEBUG-Mode I found a logfileentry like: DBUG source/send_to_listener Client has fallen too far behind, removing. I changed the queue-size in icecast.xml from 102400 to 902400 (don't know if it is a good value) but the only result is the interrupt occur some songs later. I'm realy confused, cause it is not my first icecast-setup and on an other server I&...

....1-kh5) and they work fine on (for example) winamp. The fact is that we have many listeners tuning in with mp3-web-radio's on slow connections. Some of the streams connect only once in a few time. They connect and disconnect after sending 8k. The error is: [2005-03-16 11:20:07] DBUG source/send_to_listener Client has fallen too far behind, removing I don't think it has fallen behind, because it didn't really send data yet. What can be wrong? I use the KH5 version because of the Intro feature. Thanks, Jesper My Config: <icecast> <limits> <clients>1000000&...

...this instalation in a few days ago. My ice icecast service simply stops, and I don’t know why. At access.log file, nothing strange. At error.log, I can saw this: [2019-04-12 18:33:09] INFO source/source_main listener count on /mountpoint1 now 170 [2019-04-12 18:33:09] INFO source/send_to_listener Client 46481 (79.216.20.105) has fallen too far behind, removing [2019-04-12 18:33:09] INFO source/source_main listener count on /mountpoint2 now 53 [2019-04-12 18:33:25] INFO source/send_to_listener Client 37748 (81.193.216.245) has fallen too far behind, removing [2019-04-12 18:33:25] INFO...

...al fallback file when server A is unavaliable. Both are version 2.3.3 When I listen to server B (the relay), while server A is turned off, all works fine ie I can listen to the fallback track without problem. However if I listen to Server B while server A is running then I quickly get: INFO source/send_to_listener Client 0 (xx.xx.xx.xx) has fallen too far behind, removing where xx.xx.xx.xx is my listening IP address (server A and B being remote, server B with a good internet connection (Amazon EC2), and Server A having a more patchy internet connection - hence the reason for using a relay with fallback. My...

Hi, I wrote a little patch for the stable version (also works for the svn version) to add a new configuration parameter called "client_maxtime". With this you can set a maximum connection time limit for a connected client so that you can disallow continuous listening. When the listening time exceeds the client connection will automatically be dropped. By default this feature is

...eam.HttpDataSource$InvalidResponseCodeExc eption: Response code: 401 So, after 12h trying to reproduce the error we saw what's happening. If the listener connection buffer due to anything, Icecast remove it's connection and log the item bellow: [2018-05-22 23:17:24] INFO source/send_to_listener Client 220977 (xxx.xxx.xxx.xxx) has fallen too far behind, removing My question is: 1. Why Icecast need to do this? 2. Why the client can't reconnect? 3. The error 401 is when the client tries to reconnect and our auth deny? Best, Thiago -------------- next part ----...

Hi, For some reason I see this in my logs: [2016-08-02 12:43:02] INFO source/send_to_listener Client 169 (127.0.0.1) has fallen too far behind, removing The more interesting is that it is the ffmpeg, that is listening to the source stream being removed. My setup is: Stream generator: DEVA TX, streaming 44,1 khz PCM (pcm16le) stream to icecast2 server Transcoding: VM with ffmpeg reading t...

...icecast@recordcaster.de> wrote: > Hi, > > I've a little bit trouble. I've set up an icecast 2.2.0 and an ices 0.4 > system. Every song, sometimes every two songs my playler lost the > connection to the stream and in DEBUG-Mode I found a logfileentry like: > DBUG source/send_to_listener Client has fallen too far behind, removing. > > I changed the queue-size in icecast.xml from 102400 to 902400 (don't > know if it is a good value) but the only result is the interrupt occur > some songs later. This usually means the client can't receive fast enough - possible...

...year before that, and this is a new phenomenon. A is running Icecast 2.3.1-5 B is running Icecast 2.3.2-2 (upgraded from 2.3.1 earlier today) Both machines are on Debian Stable. When the disconnect happens, the messages in the primary server's (A) log are: [2009-02-27 18:03:28] INFO source/send_to_listener Client 662536 (nn.nn.nn.nn) has fallen too far behind, removing [2009-02-27 18:03:28] DBUG source/source_main Client removed [2009-02-27 18:03:28] INFO source/source_main listener count on /XX now 33 [2009-02-27 18:03:28] DBUG stats/modify_node_event update node slow_listeners (11626) The me...

...eam.HttpDataSource$InvalidResponseCodeExc eption: Response code: 401 So, after 12h trying to reproduce the error we saw what's happening. If the listener connection buffer due to anything, Icecast remove it's connection and log the item bellow: [2018-05-22 23:17:24] INFO source/send_to_listener Client 220977 (xxx.xxx.xxx.xxx) has fallen too far behind, removing My question is: 1. Why Icecast need to do this? 2. Why the client can't reconnect? 3. The error 401 is when the client tries to reconnect and our auth deny? Best, Thiago -------------- next part -------------- An HTM...

...this feature is disabled (set to 0). This looks like a potentially useful feature. There are a number of problems in your patch, though: - unsigned/signed confusion. client_maxtime should be unsigned everywhere, not just in some places. - the check for whether to disconnect should probably be in send_to_listener, rather than directly cluttering source_main. - The formatting is messed up, inconsistent with the style of the rest of the code, and has several excessively long lines. If you could clean up those issues and send us another patch, then (assuming others agree that this looks useful), we'd be...

> you can't keep them in the main queue because you are subject to the > queue size cutoff so you either keep this within the per codec handle > structure (codec list) and/or in the block for the header pages (via the > associated pointer). The sending handlers are not really codec aware > but they do notice a change in headers. Yes, but that's the problem I'm facing:

...e situation, I'm not sure which would be best in your particular case but the current sync_point setting could be turned into a general bitmask flags, where sync point is just one and you can have codec specific allocations of those flags. Also the check_buffer routine is called before the send_to_listener. It's used to populate data from intro/fallback files or progress through the queue. You could set a special check buffer handler that checks the above refbuf_t flags. It's possible to create a per-client refbuf_t within there that hooks back into the queue. karl.

...oks like a potentially useful feature. There are a number of >> problems in your patch, though: >> - unsigned/signed confusion. client_maxtime should be unsigned >> everywhere, not just in some places. >> - the check for whether to disconnect should probably be in >> send_to_listener, rather than directly cluttering source_main. >> - The formatting is messed up, inconsistent with the style of the >> rest of the code, and has several excessively long lines. >> >> If you could clean up those issues and send us another patch, then >> (assuming others...

...for a step by step detail way of doing it. All the examples I find, fail at some point or another. Any one have a link to an idiots procedure ? Kurt, AMR.fm On 8/2/2016 4:30 AM, Roman wrote: > Hi, > > For some reason I see this in my logs: > > [2016-08-02 12:43:02] INFO source/send_to_listener Client 169 > (127.0.0.1) has fallen too far behind, removing > > The more interesting is that it is the ffmpeg, that is listening to > the source stream being removed. > > My setup is: > > Stream generator: > DEVA TX, streaming 44,1 khz PCM (pcm16le) stream to icecast2...

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

...[2018-08-29 11:49:10] DBUG stats/modify_node_event update global client_connections (2720) [2018-08-29 11:49:10] DBUG stats/modify_node_event update global clients (1331) [2018-08-29 11:49:10] DBUG client/client_read_bytes reading from connection has failed [2018-08-29 11:49:10] INFO source/send_to_listener Client 512 (179.127.XXX) has fallen too far behind, removing [2018-08-29 11:49:10] DBUG auth/queue_auth_client ...refcount on auth_t /aradiorock is now 502 [2018-08-29 11:49:10] INFO auth/queue_auth_client auth on /aradiorock has 1 pending [2018-08-29 11:49:10] DBUG source/source_main Client...

...f bandwidth on the streaming server but these do not seem to be the problem. The modem connect speeds are > 38Kbps and there is enough bandwidth available to the streaming server. I've switched on DEBUG logging and I am seeing these lines quite regularly: [2005-02-09 20:38:57] DBUG source/send_to_listener Client has fallen too far behind, removing I have a hunch that the burst-size and queue-size might have something to do with this. The limits section of my icecast.xml reads: <limits> <clients>2000</clients> <sources>100</sources> <thre...