thr3ads.net - Icecast - [icecast] my icecast problem [Aug 2004]

If this information is useful, please help other people find it:
Share via:

Thomas Vander Stichele

2004-Aug-06 14:22 UTC

[icecast] my icecast problem

Hi,

I've managed to capture some output from the log tail using debug level
4.  I couldn't capture it from the beginning, and it seems the debug info
isn't sent to the log file (is there a way to do that ?)

Here's a snippet of the log being repeated a lot of times during the few
seconds that I notice the stutter :

-> [28/Feb/2001:12:43:13] DEBUG: sock_write_bytes_or_kick: -1 err [11]
-> [28/Feb/2001:12:43:13] DEBUG: client 14 in write_data(). Function
write() returned -1 of 4096 bytes, client on chunk 19 (+0), source on
chunk 10
-> [28/Feb/2001:12:43:13] DEBUG: sock_write_bytes_or_kick: -1 err [11]
-> [28/Feb/2001:12:43:13] DEBUG: client 14 in write_data(). Function
write() returned -1 of 4096 bytes, client on chunk 19 (+0), source on
chunk 10
-> [28/Feb/2001:12:43:13] DEBUG: client 14 tried 2 times, now has 55
errors 8 chunks behind source

Through the errors, the number of errors seems to increase after a few of
these while the chunks behind source seems to decrease.

Just before the kick, I get ...

-> [28/Feb/2001:12:43:16] DEBUG: sock_write_bytes_or_kick: -1 err [11]
-> [28/Feb/2001:12:43:16] DEBUG: client 14 in write_data(). Function
write() returned -1 of 4096 bytes, client on chunk 19 (+0), source on
chunk 18
-> [28/Feb/2001:12:43:16] DEBUG: sock_write_bytes_or_kick: -1 err [11]
-> [28/Feb/2001:12:43:16] DEBUG: client 14 in write_data(). Function
write() returned -1 of 4096 bytes, client on chunk 19 (+0), source on
chunk 18
-> [28/Feb/2001:12:43:16] DEBUG: client 14 tried 2 times, now has 63
errors 0 chunks behind source

Here the chunks behind became 0.

A few of these and then :

-> [28/Feb/2001:12:43:16] Kicking client 14 [192.168.1.21] [Too many
errors (client not receiving data fast enough)] [listener], connected for
20 minutes and 29 seconds, 19394260 bytes transfered. 0 clients connected
->[28/Feb/2001:12:43:16] DEBUG: Removing connection 14 of type 0
-> [28/Feb/2001:12:43:16] DEBUG: sock_close: Closing socket 12
-> [28/Feb/2001:12:43:16] DEBUG: Closing fd 12

Client kicked.

Can I do something more to investigate this further ?

Thomas

<-*-                      -*->
I can't go away with you on a rock climbing weekend
What if something's on TV and it's never shown again
Just as well I'm not invited I'm afraid of heights
I lied about being the outdoor type
<-*- thomas@apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Kelly Lee Myers

2004-Aug-06 14:22 UTC

head link

[icecast] my icecast problem

Quick question?
Is there a way to observe the TCP/IP block numbers produced by a client
connected to a server that is not getting data fast enough or too fast in
icecast while it happens in real time? I suppose you might be able to do
this with a sniffer of some sort but I am just wondering about the accuracy
of the results. Having access to this information in real time would help
with trouble shooting. I know it did with our server development and as a
broadcaster I can watch each connection and see who is having problems
without going through the logs. If there is, can someone tell me how this
can be done? cause I would like to try this out and duplicate the problem
and watch what is really going on...
In addition is there a way to set the size of the outgoing packets or is
that completely handled by the stack and not icecast itself. Forgive me if
that sounds stupid, but I didn't really get that deep into icecast
configuration.

Thanks in advance.

Lithium.
----- Original Message -----
From: "Thomas Vander Stichele" <thomas@urgent.rug.ac.be>
To: <icecast@xiph.org>
Sent: Wednesday, February 28, 2001 3:57 AM
Subject: [icecast] my icecast problem
> Hi,
>
> I've managed to capture some output from the log tail using debug level
> 4.  I couldn't capture it from the beginning, and it seems the debug
info
> isn't sent to the log file (is there a way to do that ?)
>
> Here's a snippet of the log being repeated a lot of times during the
few
> seconds that I notice the stutter :
>
> -> [28/Feb/2001:12:43:13] DEBUG: sock_write_bytes_or_kick: -1 err [11]
> -> [28/Feb/2001:12:43:13] DEBUG: client 14 in write_data(). Function
> write() returned -1 of 4096 bytes, client on chunk 19 (+0), source on
> chunk 10
> -> [28/Feb/2001:12:43:13] DEBUG: sock_write_bytes_or_kick: -1 err [11]
> -> [28/Feb/2001:12:43:13] DEBUG: client 14 in write_data(). Function
> write() returned -1 of 4096 bytes, client on chunk 19 (+0), source on
> chunk 10
> -> [28/Feb/2001:12:43:13] DEBUG: client 14 tried 2 times, now has 55
> errors 8 chunks behind source
>
>
> Through the errors, the number of errors seems to increase after a few of
> these while the chunks behind source seems to decrease.
>
> Just before the kick, I get ...
>
> -> [28/Feb/2001:12:43:16] DEBUG: sock_write_bytes_or_kick: -1 err [11]
> -> [28/Feb/2001:12:43:16] DEBUG: client 14 in write_data(). Function
> write() returned -1 of 4096 bytes, client on chunk 19 (+0), source on
> chunk 18
> -> [28/Feb/2001:12:43:16] DEBUG: sock_write_bytes_or_kick: -1 err [11]
> -> [28/Feb/2001:12:43:16] DEBUG: client 14 in write_data(). Function
> write() returned -1 of 4096 bytes, client on chunk 19 (+0), source on
> chunk 18
> -> [28/Feb/2001:12:43:16] DEBUG: client 14 tried 2 times, now has 63
> errors 0 chunks behind source
>
> Here the chunks behind became 0.
>
> A few of these and then :
>
> -> [28/Feb/2001:12:43:16] Kicking client 14 [192.168.1.21] [Too many
> errors (client not receiving data fast enough)] [listener], connected for
> 20 minutes and 29 seconds, 19394260 bytes transfered. 0 clients connected
> ->[28/Feb/2001:12:43:16] DEBUG: Removing connection 14 of type 0
> -> [28/Feb/2001:12:43:16] DEBUG: sock_close: Closing socket 12
> -> [28/Feb/2001:12:43:16] DEBUG: Closing fd 12
>
> Client kicked.
>
> Can I do something more to investigate this further ?
>
> Thomas
>
> <-*-                      -*->
> I can't go away with you on a rock climbing weekend
> What if something's on TV and it's never shown again
> Just as well I'm not invited I'm afraid of heights
> I lied about being the outdoor type
> <-*- thomas@apestaart.org -*->
> URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
>
>
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> icecast project homepage: http://www.icecast.org/
> To unsubscribe from this list, send a message to
'icecast-request@xiph.org'> containing only the word 'unsubscribe' in the body.  No subject is
needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
>
--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Sean /The RIMBoy/

2004-Aug-06 14:22 UTC

head link

[icecast] my icecast problem

On Wed, 28 Feb 2001, Kelly Lee Myers wrote:
> In addition is there a way to set the size of the outgoing packets or is
> that completely handled by the stack and not icecast itself. Forgive me if
> that sounds stupid, but I didn't really get that deep into icecast
> configuration.
You can... but... 

Someone correct me if I'm wrong, but you want to look at the MTU for your
interface.

However, you'll probably see little if any difference and you may effect
performance for not only you, but your router(s) and that in turn would
effect your listeners.  Unless you have control over the routers and know
what type of topology the upstream connect runs (FDDI, ATM, etc) then
there is really no point in playing with the packet size.  Most OS's by
default are already using optimized packet sizes.  

HTH,

Sean..

-- 
A flute with no holes is not a flute.  A donut with no hole is a danish.
	--Chevy Chase, Caddyshack
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
www.rimboy.com		<-- Your source for the crap you know you need.
www.rimboy.com/rimdistro/rimiradio  <-- Icecast server on a floppy! (i486+)

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Possibly Parallel Threads

Search for more apparently analagous threads

Icecast - Aug 2004 - my icecast problem

[icecast] my icecast problem

[icecast] my icecast problem

[icecast] my icecast problem

Possibly Parallel Threads