karlheyes / icecast-kh Goto Github PK

Today i updated from the commit of the 2-dic to last one
testing it, at 320 kb, on fast manual disconnect->reconect
the server gets stuck, it does not crash, but it dont respond anymore to clients or sources
nor the web interface...
but seen the status of the service it is "up", so is not a crash

:3 replicated plenty of times

regards and happy x-mas and now happy new year!

My previous Icecast install (2.3.2-9 on Debian Wheezy) was just updated to 2.3.3-kh2. Trying to listen to music (MP3 and Ogg format) on the KH2 version would result in a short blip of music, "invalid format/corrupted data" from my Foobar2000 client, and then Icecast would disconnect my source from the server.

I found "source_read queue oddity" in my log files corresponding to this. I managed to play whack-a-mole with my icecast.xml and found out that my burst-size setting of 0 was causing this. I normally set burst-size to 0 for my Shoutcast-based relays, which tune in as normal clients, to reduce buffer bloating. (there are reasons for this) Icecast 2.3.3-kh2 does not allow this to happen. I did not experiment with smaller burst sizes, as my 200+ listener station was waiting, but setting the burst-size value to the default 64Kb eliminated the issue and allowed music to play again.

Hello

The server runs on Windows.

If 252 or more connections - new connections are not made and available statistics page - the server denies access (error 403).

Server version - 33, 29 repeated the error.

How can I solve this problem?

Thanks

Hello Karl,

There is the possibility of integrating the transmission of video format. Flv in icecast?

Formats. And ogg. WebM are still very futuristic, because stability is small in most browsers and works only in browsers updated.

I know the tendency is to use. WebM, plus many of us who use this excellent tool for the transmission of audio, we miss the format. In flv videos as well.

This is because we have great difficulty in integrating the videos without using a flash.

causing inconvenience to the users, since some can watch the videos and not others.

please, consider my request for videos available in. flv.

Congratulations on the excellent work, you should be congratulated.

Thank you,

David.

Rather than stating a specific user and password for administration in the config file, i'd be neat if we could authenticate against the admin user interface using url auth. This would allow for more control over who can access the admin interface and who can't. Also passwd and command authentication could be great additions in this situation.

Its return a full header for mp4 (AAC/H.264)? for use in playes html5?

Hello. After the release of version kh31 (win32) and all subsequent charset error appeared on web page of icecast server. Example:
Mount Start: Fri, 25 May 2012 00:49:02 ��������� ����� (����).

I am using 2 types of stream for each user, one /live and other /live.auto. autodj is in .auto.
when somebody streams into /live i cannot see the id3 info. /live fallsback to /live.auto.

on "mount_add" the php is getting -->
action=mount_add&mount=%2Fstream&server=localhost&port=9000&ip=

there is the ip key, but no ip.

updated today --> 432dcc5

pd: is this place a good place to put issues ?

Hi,

I could not run the version 2.3.3 KH6. localhost works normal, but when the stream is accessed by a client it simply does not connect in the stream, beyond which no stabilizes the page (meusite.com.br: 8003) Erro 324 (net::ERR_EMPTY_RESPONSE)

The version 2.3.3 KH5 the server is running normally

The system is installed on windows server 2003.

wait, thanks.

whit and ulr auth

when a source connect to /stream, it ask for /stream user/pass and mount the stream as /stream

and if a listener ask for /stream it ask for /stream.mp3 user/pass and and send it to /stream.mp3

shouldn't the source auth and stream redirected to"/stream.mp3" ?

that error is show in winamp when trying to connect to a stream, is persistent, cant conect
it happend in one of the last 3 commits

downgraded to kh7 and it works fine

(as per http://icecast.imux.net/viewtopic.php?p=22589#22589)

Hi Karl,

I've just noticed some slightly weird behaviour with this using the latest github sources... If i try to include more than a single mount or relay definition in the included xml, then I get an error: parser error : Extra content at the end of the document.

I'm trying to include both a and a in each included file, but am currently having to put these in separate files.

Hello,

I am serving mp3 files with in KH3 seeking works, but with KH5 the Content-Length is not sent to the client.

I hope this can be fixed.

Yours,
bbk

Hello,

it is possible to stream videos in . flv format?

This feature avoids the use of other software for the transmission of video, as wonza.

congratulations for the work!

Does any one has seen crashes of 2.3.2 KH31 and 2.3.3 KH1 similar like:

KH31:

Thread 1 (Thread 10096):
#0  signal_segv (signum=11, info=0x7f67e3b0c970, ptr=0x7f67e3b0c840) at ./Common/SIGSEGVHandler.cpp:111
#1  <signal handler called>
#2  0x00007f67e17068fa in pthread_rwlock_wrlock () from /lib/libpthread.so.0
#3  0x000000000042d8cd in thread_rwlock_wlock_c (rwlock=0x40, line=1171, file=0x4390b8 "avl.c") at thread.c:542
#4  0x0000000000415652 in stats_lock (handle=140082310717968, mount=0x1 <Address 0x1 out of bounds>) at stats.c:1304
#5  0x0000000000412d1f in update_source_stats (source=0x7f675d5b1980) at source.c:366
#6  0x00000000004143c8 in source_read (source=0x7f675d5b1980) at source.c:438
#7  0x00000000004181cb in worker (arg=) at client.c:529
#8  0x000000000042dfb9 in _start_routine (arg=0x16bcb30) at thread.c:660
#9  0x00007f67e17028ba in start_thread () from /lib/libpthread.so.0
#10 0x00007f67e19e702d in clone () from /lib/libc.so.6
#11 0x0000000000000000 in ?? ()

2.3.3 KH1:

Thread 1 (Thread 8295):
#0  signal_segv (signum=11, info=0x7f8dd7fe6930, ptr=0x7f8dd7fe6800) at ./Common/SIGSEGVHandler.cpp:111
#1  <signal handler called>
#2  0x00007f8ddcb278fa in pthread_rwlock_wrlock () from /lib/libpthread.so.0
#3  0x00000000004302fd in thread_rwlock_wlock_c (rwlock=0x2e, line=1171, file=0x43c348 "avl.c") at thread.c:546
#4  0x0000000000416762 in stats_lock (handle=154346384, mount=0x1 <Address 0x1 out of bounds>) at stats.c:1324
#5  0x0000000000413b54 in update_source_stats (source=0x7f8dd003cea0) at source.c:360
#6  0x00000000004153b0 in source_read (source=0x7f8dd003cea0) at source.c:444
#7  0x000000000040ec98 in relay_read (client=0x938d9b0) at slave.c:1306
#8  0x000000000041945b in worker (arg=) at client.c:557
#9  0x00000000004309e9 in _start_routine (arg=0x25f8fa0) at thread.c:664
#10 0x00007f8ddcb238ba in start_thread () from /lib/libpthread.so.0
#11 0x00007f8ddce0802d in clone () from /lib/libc.so.6
#12 0x0000000000000000 in ?? ()

AFAICS there is a problem / race condition in function

long stats_lock (long handle, const char *mount)

while calling

avl_tree_wlock.

This is a sporadic error. Hard to reproduce.
But this happend last time, as I tried to restart the server process, while thousands of clients tried to connect to this slave (relay) server. So it was "during initialisation / connecting sources from master server". Maybe this helps?

Matthias

Error not loading authentication.

[2012-10-16 14:11:39] EROR auth/get_authenticator Auth URL disabled

Config:

    <mount>
            <mount-name>/stream1.live.mp3</mount-name>
            <fallback-mount>/stream1.bot.mp3</fallback-mount>
            <fallback-override>1</fallback-override>
            <hidden>1</hidden>
            <no-yp>1</no-yp>
            <authentication type="url">
                    <option name="stream_auth" value="http://www.aniradio.org/auth.php"/>
                    <option name="username" value="user"/>
                    <option name="password" value="pass"/>
                    <option name="auth_header" value="HTTP 200 OK"/>
                    <option name="timelimit_header" value="auth_get_url_auth:"/>
            </authentication>
    </mount>

Hi Karl,

I have tested both KH31 and KH33 in a production environment and this issue happens on both versions, while with same config the Debian stable version 2.3.2 does not have this issue.

So the issue is as following:
After some time the server stops accepting connections on one of the 2 configured "listen-sockets". The one that always fails is the "*:83" listen-socket, while the other "VIP:80" (VIP=virtual ip address) always works. The VIP I use for my load balancer, and the Icecast server is always working ok and accepting connections from this IP on port 80, but stops accepting connections on private IP and port 83 (for which I use the *:83 "listen-socket").

My Icecast config is as following:

 <listen-socket>
    <port>80</port>
    <bind-address>"my VIP"</bind-address>
 </listen-socket>

 <listen-socket>
    <port>83</port>
    <bind-address>*</bind-address>
 </listen-socket>

In error.log there is no error messages indicating any issues when the ":83" socket fails.
And when the server is in this state I get the following netstat info when I try to connect to the KH33/KH31 Icecast server via "privateIP:83":
xxx@yyy-193:~$ netstat -an |grep :83
tcp 0 0 0.0.0.0:83 0.0.0.0: LISTEN
tcp 0 0 10.5.90.193:83 10.5.90.30:58335 SYN_RECV
tcp 0 0 10.5.90.193:83 10.5.90.31:46669 SYN_RECV
tcp 0 0 10.5.90.193:83 10.5.90.31:46670 SYN_RECV

And here is same netstat from a working Icecast 2.3.2 (Debian stable version):
xxx@yyy-191:~$ netstat -an |grep :83
tcp 0 0 0.0.0.0:83 0.0.0.0:* LISTEN
tcp 0 0 10.5.90.191:83 10.5.90.31:44202 ESTABLISHED

So as we can see on the KH version server the connection gets "stuck" on "SYN_RECV", even though we can see that the "listen-socket :83" is still active from "tcp 0 0 0.0.0.0:83 0.0.0.0: LISTEN".

I did some investigation from logs and I noticed something weird.

• 00:00h -> logrotate does reload of Icecast at this time:

[2012-08-24 00:00:10] INFO connection/connection_listen_sockets_close Leaving port 80 ("my VIP") open
[2012-08-24 00:00:10] INFO connection/connection_listen_sockets_close Leaving port 83 (*) open
[2012-08-24 00:00:10] INFO client/workers_adjust requested worker count 1
[2012-08-24 00:00:10] INFO connection/connection_thread_shutdown shutting down connection thread
[2012-08-24 00:00:10] INFO thread/ lock abort set to 0
[2012-08-24 00:00:10] INFO source/source_read listener count on /xxx/yyy.ogg now 26
[2012-08-24 00:00:10] INFO event/event_config_read Re-reading XML
[2012-08-24 00:00:10] INFO source/source_apply_mount Applying mount information for "/blabla/bleble"
.
.
.
[2012-08-24 00:00:10] INFO connection/get_ssl_certificate No SSL capability
[2012-08-24 00:00:10] INFO connection/connection_thread connection thread started

Here we can see that at "00:00h" both "listen-sockets" are ok from these 2 lines:
[2012-08-24 00:00:10] INFO connection/connection_listen_sockets_close Leaving port 80 ("my VIP") open
[2012-08-24 00:00:10] INFO connection/connection_listen_sockets_close Leaving port 83 (*) open

• 00:07h -> last entries in error log before I did reload in the morning "08:14h":
  [2012-08-24 00:07:05] INFO source/source_apply_mount Applying mount information for "/yyy"
  [2012-08-24 00:07:05] INFO slave/relay_reset servers to be retried on /yyy
  [2012-08-24 00:07:05] INFO slave/relay_read standing by to restart relay on /yyy
  [2012-08-24 00:07:05] INFO source/source_shutdown Source "/yyy" exiting
  [2012-08-24 00:07:05] INFO slave/relay_read fallback on /yyy not attempted
  [2012-08-24 00:07:05] INFO slave/relay_reset servers to be retried on /yyy
  [2012-08-24 00:07:04] INFO source/source_read listener count on /yyy now 0
  [2012-08-24 00:07:04] INFO source/send_listener Client 38733 (41.181.32.21) has fallen too far behind on /yyy, removing
  [2012-08-24 00:06:55] INFO source/source_read listener count on /yyy now 1
  [2012-08-24 00:06:55] INFO source/send_listener Client 84613 (177.98.149.121) has fallen too far behind on /yyy, removing
  [2012-08-24 00:06:55] INFO source/send_listener Client 80720 (189.203.203.42) has fallen too far behind on /yyy, removing
  [2012-08-24 00:06:53] INFO source/source_read listener count on /yyy now 3
  [2012-08-24 00:06:53] INFO source/send_listener Client 82325 (84.246.147.159) has fallen too far behind on /yyy, removing
  [2012-08-24 00:06:53] INFO source/send_listener Client 46119 (98.92.248.160) has fallen too far behind on /yyy, removing
  [2012-08-24 00:06:52] INFO source/source_apply_mount Applying mount information for "/xxx"
  [2012-08-24 00:06:52] INFO slave/relay_reset servers to be retried on /xxx
  [2012-08-24 00:06:52] INFO slave/relay_read standing by to restart relay on /xxx
  [2012-08-24 00:06:52] INFO source/source_shutdown Source "/xxx" exiting
  [2012-08-24 00:06:52] INFO slave/relay_read fallback on /xxx not attempted
  [2012-08-24 00:06:52] INFO slave/relay_reset servers to be retried on /xxx
  [2012-08-24 00:06:52] INFO source/source_read listener count on /yyy now 5
  [2012-08-24 00:06:52] INFO source/source_read listener count on /xxx now 0
• 08:14h -> I did manual "reload" of config on the KH33 server, and noticed this in error.log:
  [2012-08-24 08:14:34] INFO connection/connection_listen_sockets_close Leaving port 80 ("my VIP") open
  [2012-08-24 08:14:34] INFO connection/connection_listen_sockets_close Leaving port 80 ("my VIP") open
  [2012-08-24 08:14:34] INFO client/workers_adjust requested worker count 1
  [2012-08-24 08:14:34] INFO connection/connection_thread_shutdown shutting down connection thread
  [2012-08-24 08:14:34] INFO thread/ lock abort set to 0
  [2012-08-24 08:14:34] INFO event/event_config_read Re-reading XML
  [2012-08-24 08:14:34] INFO connection/connection_thread connection thread finished
  [2012-08-24 08:14:34] INFO connection/wait_for_serversock HUP received, reread scheduled
  .
  .
  .
  [2012-08-24 08:14:34] INFO connection/get_ssl_certificate No SSL capability
  [2012-08-24 08:14:34] INFO connection/connection_thread connection thread started

So after reload instead of having this (when it works):
[2012-08-24 00:00:10] INFO connection/connection_listen_sockets_close Leaving port 80 ("my VIP") open
[2012-08-24 00:00:10] INFO connection/connection_listen_sockets_close Leaving port 83 (*) open

it has this (2x the port 80 listen-socket, and no port 83 listen-socket):
[2012-08-24 08:14:34] INFO connection/connection_listen_sockets_close Leaving port 80 ("my VIP") open
[2012-08-24 08:14:34] INFO connection/connection_listen_sockets_close Leaving port 80 ("my VIP") open

Today I changed the Icecast KH config to bind on privateIP:83 instead of *:83 to see if this same issue will reoccur:

 <listen-socket>
    <port>80</port>
    <bind-address>"my VIP"</bind-address>
 </listen-socket>

 <listen-socket>
    <port>83</port>
    <bind-address>10.5.90.193</bind-address>
 </listen-socket>

Regards,

Karl,

As discussed on the icecast forums, it would be really great if there was a way to pass back other mountpoint specific parameters when using stream_auth for external source authentication.

max_listeners is the main one, however being able to specify other parameters would also be very useful.

Ideally I would like to return a block of xml in the auth response that contains all the mount parameters and have these parsed as if they had been contained in icecast.xml

Cheers.

Hello

Sorry for my bad english)

There is a problem - in version 33 song titles amperdans is lost. This is very critical for song titles, in which there are a few artists. In version 29 it works normally

Hello,

I have two suggestions.

1 - Insert a Transcoder in icecast.

                                                                               -- aac 96 kbps     ------ localhost:8000/aac96
                                                                              -- aac 48 kbps     ------ localhost:8000/aac48

source --> aac 96 kbps --- Server icecast --- -- mp3 64 kbps ------ localhost:8000/mp364
-- ogg 24 kbps ------ localhost:8000/ogg24
-- webm 32 kbps ------ localhost:8000/webm32

http://svn.oddsock.org/public/trunk/streamTranscoderv3/

the Transcoder will bring a very strong differential for icecast, and no other solution offers this free service in a single software.

Facilitate integration with html5 websites, and saved up the banda the source.

2 - Create a log file with data from listeners, to facilitate data collection system for Statistics and save memory.

Congratulations for the work.

regards,

David.

Hello!

In version 33.5 server, I noticed the change of the parameter Peak Listeners down. Initially, there were about 240, then suddenly dropped to 121. How is this possible? It was interrupted sound.

On the same server running version 29.1 and it has not changed this setting.

I put the error log from version 33.5 http://clck.ru/d/YaxcCxpQ1BifN

Alex.

Hi!

While in-browser playback (HTML5 ) of mp3/ogg streams in WebKit-based browsers (tested with Safari 6.0.2 and Chrome 24) worked with 2.3.3-kh5, it fails with the current git version.

Hi Karl,

there seems to be an isse in format_mp3.c.
After several weeks a KH3 crashed with following stack trace:
#0 signal_segv (signum=11, info=0x7f3189855930, ptr=0x7f3189855800) at ./Common/SIGSEGVHandler.cpp:128
#1 <signal handler called>
#2 0x00000000004242e3 in format_mp3_write_buf_to_client (client=0x7f30e0994a10) at format_mp3.c:527
#3 0x00000000004244eb in write_mpeg_buf_to_client (client=0x7f30e0994a10) at format_mp3.c:605
#4 0x0000000000414dad in send_listener (client=0x7f30e0994a10) at source.c:1078
#5 send_to_listener (client=0x7f30e0994a10) at source.c:953
#6 0x00000000004195ab in worker (arg=) at client.c:561
#7 0x00000000004312b9 in _start_routine (arg=0x7c3dd0) at thread.c:673
#8 0x00007f31874458ba in start_thread () from /lib/libpthread.so.0
#9 0x00007f318772a02d in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()

according it it's sources crash happens in format_mp3.c:527 :

format_mp3.c:522 refbuf_t *refbuf = client->refbuf;
...
format_mp3.c:527 len = refbuf->len - client->pos;

AFAICS while in between there is no check if refbuf is NULL

format_mp3.c in current sources looks similar.

Thanks
Matthias

ups ?
from kh5 to kh6 when updated the day 18-2, aparenttly this is broken on (dis)connect
downgraded to kh5 and it works.

the sh just moves the dump file on disconnect

the on(diconect) must be configured in another way ? cose the new arg[ ] fuction ?

centos 5.9

My icecast setup is pretty vanilla - the only real difference from the norm is that I have listener_add and listener_remove calling a PHP script which adds and removes a row to a MySQL database for that listener's session.

The script is really basic, and I'm very confident it's not to blame here. The MySQL database is also local, using a stable build, etc., etc.
Quite rarely, listener_remove somehow won't call the PHP script when a listener drops. I haven't been able to replicate the situation where this occurs. It might happen once every couple weeks, but it's enough to throw off my stats.

I rarely restart Icecast itself, but I do kill -HUP every couple weeks for config changes.

Any pointers on where I should be looking to recreate this issue so it can get fixed?

I'm using KH5 and have a 128kbps, 44100hz mp3 stream, with a defined fallback option stating a static file of the same format in the webroot. De static file isn't being detected as a fallback, and thus the clients connecting to the stream are disconnected rather than forwarded to the static file. Using another connected source as a fallback mount works as expected.

I was wondering if you could answer a very quick query for me, because I've struggled to spot a specific point in the code where this could be happening.

Does Icecast attempt any manipulation of inline meta (as in meta interval regular segment of length byte, meta string, then return to audio frames), in particular moving its position in in relation to the audio frames in any way?

I am attempting to use specific positioning of injected inline meta in relation to the audio (in my specific example AAC+ encapsulated in ADTS frames). If I connect direct to my original source I am correctly aligning the meta as I expect, yet when I pass the feed through Icecast it appears that the position of the meta intervals are changing (still at the required regular interval, but the bytes either side of the meta interval component don't appear to match).

Does this ring any bells in terms of implementation specifics in Icecast or is this misleading and in fact an issue somewhere elsewhere in my project?

Thank you for your time.

I have a fallback mount, which is a static file, limit-rate 129000. When i'm broadcasting on the main mount and stop broadcasting, everything works as expected, the fallback takes place. However, when reconnecting the stream, the fallback override really takes ages. For example, when i disconnect the stream for one second and then reconnect again, the fallback stream is played for like 10 seconds. So the fallback stream is played like 10 times the time that the actual main stream is disconnected.
How to solve this issue, or is it a bug? I'd like to have the fallback override take place as soon as the actual stream is being (re)connected, not like 30 seconds or even more afterwards. What meganism and variables are important for the fallback process to take place asap?

testing/using this flash player - > http://www.fastserv.com/kb/article/icecast_embedded_flash_player/
i notice that when ppl conect it send the auth to the mount but as ...&mount=/stream?type=.flv&...
should it be "...&mount=/stream&type=.flv&..." or "...&mount=/stream&type=flv&..." or "...&mount=/stream&..."??

on metadata update whit shoutcast, icecast sends the authentication request, whitout user or pass, just the admin=1
is that suposed to be ?

Hi Karl,

for testing I put a KH1 in production (as a slave - without having own sources).
As it seems it's not stable.
Yesterday four crashes. Today already one.
Cause or initiator for the crashes yesterday was, that the connection to the master server was broken (or better: the master server itself was not running for some minutes) while the crashed server was under user load (around 3k connections).
Interesting is, that another KH1, which was connected to the same master server, did not crash. But this second server had no client connections on it. So it's a issue while listerners are connected and the source goes down (my guess).
The crash today was caused (AFAICS) because a single source got disconnected. So basicly it should be the same error.
Here are the 5 stack traces (the first 4 yesterday - the 5th today):

Crash number 3 looks different. So we have two issues?

Crash1:

Thread 1 (Thread 15449):
#0  signal_segv (signum=11, info=0x7ff2ef6309b0, ptr=0x7ff2ef630880) at ./Common/SIGSEGVHandler.cpp:128
#1  <signal handler called>
#2  0x00007ff2f44027f0 in memcpy () from /lib/libc.so.6
#3  0x0000000000418d18 in refbuf_copy (orig=0x7ff2c437a1a0) at refbuf.c:74
#4  0x0000000000414a5f in source_listener_detach (source=0x12e5480, client=<value optimized out>) at source.c:885
#5  0x0000000000414d2f in source_listener_release (client=0x7ff2d5abb9d0) at source.c:1861
#6  send_to_listener (client=0x7ff2d5abb9d0) at source.c:958
#7  0x000000000041945b in worker (arg=<value optimized out>) at client.c:557
#8  0x00000000004309e9 in _start_routine (arg=0x12af7f0) at thread.c:664
#9  0x00007ff2f416d8ba in start_thread () from /lib/libpthread.so.0
#10 0x00007ff2f445202d in clone () from /lib/libc.so.6
#11 0x0000000000000000 in ?? ()


Crash2:

Thread 1 (Thread 20238):
#0  signal_segv (signum=11, info=0x7f4026b6e9b0, ptr=0x7f4026b6e880) at ./Common/SIGSEGVHandler.cpp:128
#1  <signal handler called>
#2  0x00007f402b9407f0 in memcpy () from /lib/libc.so.6
#3  0x0000000000418d18 in refbuf_copy (orig=0x1dd09a0) at refbuf.c:74
#4  0x0000000000414a5f in source_listener_detach (source=0x7f40144c2830, client=<value optimized out>) at source.c:885
#5  0x0000000000414d2f in source_listener_release (client=0x7f401415ef50) at source.c:1861
#6  send_to_listener (client=0x7f401415ef50) at source.c:958
#7  0x000000000041945b in worker (arg=<value optimized out>) at client.c:557
#8  0x00000000004309e9 in _start_routine (arg=0x15457f0) at thread.c:664
#9  0x00007f402b6ab8ba in start_thread () from /lib/libpthread.so.0
#10 0x00007f402b99002d in clone () from /lib/libc.so.6
#11 0x0000000000000000 in ?? ()


Crash3:

Thread 1 (Thread 20804):
#0  signal_segv (signum=11, info=0x7ff6a9d7e9b0, ptr=0x7ff6a9d7e880) at ./Common/SIGSEGVHandler.cpp:128
#1  <signal handler called>
#2  0x0000000000423e2f in send_iceblock_to_client (client=0x7ff6a674d180) at format_mp3.c:558
#3  write_mpeg_buf_to_client (client=0x7ff6a674d180) at format_mp3.c:599
#4  0x0000000000414f1d in send_listener (client=0x7ff6a674d180) at source.c:1079
#5  send_to_listener (client=0x7ff6a674d180) at source.c:954
#6  0x000000000041945b in worker (arg=<value optimized out>) at client.c:557
#7  0x00000000004309e9 in _start_routine (arg=0xeb77f0) at thread.c:664
#8  0x00007ff6ae8bb8ba in start_thread () from /lib/libpthread.so.0
#9  0x00007ff6aeba002d in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()


Crash4:

Thread 1 (Thread 22120):
#0  signal_segv (signum=11, info=0x7f8ef41b59b0, ptr=0x7f8ef41b5880) at ./Common/SIGSEGVHandler.cpp:128
#1  <signal handler called>
#2  0x00007f8ef8f877f0 in memcpy () from /lib/libc.so.6
#3  0x0000000000418d18 in refbuf_copy (orig=0x7f8ec99a2a00) at refbuf.c:74
#4  0x0000000000414a5f in source_listener_detach (source=0x7f8ed8004020, client=<value optimized out>) at source.c:885
#5  0x0000000000414d2f in source_listener_release (client=0x3d51c80) at source.c:1861
#6  send_to_listener (client=0x3d51c80) at source.c:958
#7  0x000000000041945b in worker (arg=<value optimized out>) at client.c:557
#8  0x00000000004309e9 in _start_routine (arg=0x24ec7f0) at thread.c:664
#9  0x00007f8ef8cf28ba in start_thread () from /lib/libpthread.so.0
#10 0x00007f8ef8fd702d in clone () from /lib/libc.so.6
#11 0x0000000000000000 in ?? ()


Crash5:

Thread 1 (Thread 25085):
#0  signal_segv (signum=11, info=0x0, ptr=<value optimized out>) at ./Common/SIGSEGVHandler.cpp:128
#1  <signal handler called>
#2  0x00007ff0a69797f0 in memcpy () from /lib/libc.so.6
#3  0x0000000000418d18 in refbuf_copy (orig=0x7ff06f977210) at refbuf.c:74
#4  0x0000000000414a5f in source_listener_detach (source=0xb7f330, client=<value optimized out>) at source.c:885
#5  0x0000000000414d2f in source_listener_release (client=0x7ff034c1d800) at source.c:1861
#6  send_to_listener (client=0x7ff034c1d800) at source.c:958
#7  0x000000000041945b in worker (arg=<value optimized out>) at client.c:557
#8  0x00000000004309e9 in _start_routine (arg=0xa1b270) at thread.c:664
#9  0x00007ff0a66e48ba in start_thread () from /lib/libpthread.so.0
#10 0x00007ff0a69c902d in clone () from /lib/libc.so.6
#11 0x0000000000000000 in ?? ()

Matthias

I'm not sure is this a real bug, but the behavior is unexpected to me. When you open a tab in Chrome or Firefox and play an icecast stream (for example, http://mp3.nashe.ru/best-128.mp3), it plays well. But if you open one more tab with the same url, it doesn't start to play. Moreover, when you close the first tab, the second starts to play.

When you open one tab in Chrome and another in Firefox, both play well. It seems that the browser doesn't want to open another connection to the Icecast and waits until the first one is finished (keep-alive?). On the other hand, if the streams are different mounts on the same server, they both play well.

Do you know what's happening here? Is this a bug? Can it be fixed?
I've checked versions 2.3.2-kh32 to 2.3.3-kh6 and browsers Chrome, Firefox.
IE9 & Opera seem to work fine.

Having the latest Icecast KH installed here on my windows pc, i use edcast for streaming to the icecast Server.

Have reinstalled it today and switched to the minum configuration file - but no change.

The problem is this, Whenever i start a radio session, After a streaming time of around 2,5-3 hours the stream quality goes to hell - it sounds disorted, and listeners only hear constantly heavy buffering/skipping.

In the Config there is only the minimum on settings, whats necessary, host, port, directories,logs. No buffer related Values or something like that.

Its just strange, perhaps some kind of bug?

Anyway, guess it was not wrong to report things like that.

Friendly Greetings :)

suggestion from Ricky @ galaxyweb

play intro like content on source switch over. may be independent of intro file

karl

if you configure 2 mounts in an include it fails to parse, something like:

is this suposed to be ?

I don't know it's a bug. If yes it's a minor one.
In v2.3.2 the date/time was formatted like:

server_start Fri, 06 Jul 2012 02:21:45 +0200

In 2.3.3KH1 it looks like:

server_start 05/Jul/2012:21:46:43 +0200

Why is date and time delimited by a colon?

Regards
Matthias

I'd like to suggest the ability for stream dump names to contain the mountname. This allows defining of wildcarded mounts with separate streamdump filenames. For example:

<mount>
<mount-name>/stream*.mp3</mount-name>
<!- this would dump to /home/icecast/streamdump/stream*.mp3, so stream2.mp3 when stream2 mount is connected and streamx.mp3 when streamx is connected -->
<dump-file>/home/icecast/streamdump/%mount</dump-file>
<!- this would dump to /home/icecast/streamdump/dump*.mp3, so dump2.mp3 when stream2 mount is connected and dumpx.mp3 when streamx is connected -->
<dump-file>/home/icecast/streamdump/dump*.mp3</dump-file>
</mount>```
any thoughts?

Let's discuss following setup. We have first mount with max-listeners limited:

/nashe-192
1
/nashe-128.mp3
1

And we have fallback mount:

/nashe-128.mp3
5700
/nashe-64.mp3
1

When first mount is full, function source.c/source_add_listener() tries to find fallback mount for client, it founds it, updates "mount" string and continues with loop but forgets to update "minfo" structure.

For second loop iteration, if fallback mount is full too, it does not update "minfo" again, so loop would be endless without built-in loop breaker (10 iteration max) but this leads us to 403 error being sent to the user instead of serving it with next fallback.

Next, while checking for "max-listeners" limit this loop always compares current listeners count with original mount's limit instead of limit for fallback. So, in our case current listeners count is always compared with 1. This behavour differs from icecast-2.3.3 branch, is unexpected and undesirable. It often leads to non-working fallback when first mount has low limit.

The following patch fixes both problem for us and makes us allowed to use "internal mount redirects" like described above.

--- src/source.c.orig 2013-04-02 21:16:12.000000000 +0400
+++ src/source.c 2013-04-02 22:20:47.000000000 +0400
@@ -2022,7 +2022,7 @@
if (mountinfo->max_listeners == -1)
break;

•        if (source->listeners < (unsigned long)mountinfo->max_listeners)
  

•        if (source->listeners < (unsigned long)minfo->max_listeners)
           break;
       INFO1 ("max listener count reached on %s", source->mount);
   }
  

  @@ -2031,6 +2031,7 @@
  {
  thread_rwlock_unlock (&source->lock);
  mount = minfo->fallback_mount;

•        minfo = config_find_mount (config_get_config_unlocked(), mount);
       INFO1 ("stream full trying %s", mount);
       loop--;
       continue;
  

When streaming an OGG stream via icecast, it is not possible to update the metadata of the stream. The update is triggered via the web interface at:
/admin/metadata.xsl?song=xxxx&mount=/xxxx.ogg&mode=updinfo&charset=UTF-8

As far as I can see from the source code the hook to set the metadata is not implemented for OGG (plugin->set_tag = NULL; (line 170 in format_ogg.c).

However the update command responds with:

Message : Metadata update successful
Return Code: 1

It would be great if this could be implemented for OGG. But if that's impossible, an error code should be returned when the metadata update is not supported for the current stream (in my opinion).

got a kind of nasty crash.

as you know im using 2 mounts /stream and /falback , the two of them are sourced streams

i updated today to the last kh then while disconnecting /fallback whit / stream been sourced it crashed
the nasty part, is that the error log at debug level shows no error, but the process itself is gone

this are the last debug lines

[2012-08-05 03:16:42] DBUG stats/modify_node_event update "/stream" total_bytes_read (2312150)
[2012-08-05 03:16:42] DBUG stats/modify_node_event update "/stream" total_bytes_sent (4613120)
[2012-08-05 03:16:42] DBUG stats/modify_node_event update "/stream" total_mbytes_sent (4)
[2012-08-05 03:16:42] DBUG stats/modify_node_event update "/stream" queue_size (524121)
[2012-08-05 03:16:42] DBUG stats/modify_node_event update "/stream" connected (193)
[2012-08-05 03:16:42] DBUG stats/modify_node_event update "global" stream_kbytes_sent (25150)
[2012-08-05 03:16:42] DBUG stats/modify_node_event update "global" stream_kbytes_read (17673)
[2012-08-05 03:16:42] DBUG stats/modify_node_event update "global" banned_IPs (0)
[2012-08-05 03:16:42] DBUG stats/modify_node_event update "global" outgoing_kbitrate (265643)
[2012-08-05 03:16:43] DBUG stats/modify_node_event update "global" banned_IPs (0)
[2012-08-05 03:16:43] DBUG stats/modify_node_event update "global" outgoing_kbitrate (512823)
[2012-08-05 03:16:44] DBUG stats/modify_node_event update "global" banned_IPs (0)
[2012-08-05 03:16:44] DBUG stats/modify_node_event update "global" outgoing_kbitrate (516905)
[2012-08-05 03:16:45] INFO source/source_read End of Stream /fallback
[2012-08-05 03:16:45] INFO source/source_shutdown Source "/fallback" exiting
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "/fallback" outgoing_kbitrate (0)
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "/fallback" incoming_bitrate (47592)
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "/fallback" total_bytes_read (1601495)
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "/fallback" total_bytes_sent (704512)
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "/fallback" total_mbytes_sent (0)
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "/fallback" queue_size (65201)
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "/fallback" connected (267)
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "global" stream_kbytes_read (17700)
[2012-08-05 03:16:45] INFO auth/auth_stream_end request source end for "/fallback"
[2012-08-05 03:16:45] DBUG auth/queue_auth_client starting auth thread 0
[2012-08-05 03:16:45] DBUG auth/queue_auth_client auth on /fallback has 1 pending
[2012-08-05 03:16:45] INFO source/source_set_fallback No fallback on /fallback
[2012-08-05 03:16:45] DBUG source/source_client_read removing source /fallback from tree
[2012-08-05 03:16:45] INFO source/source_client_read no more listeners on /fallback
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "/fallback" listeners (0)
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "global" sources (1)
[2012-08-05 03:16:45] DBUG source/source_clear_source clearing source "/fallback"
[2012-08-05 03:16:45] INFO source/_free_source freeing source "/fallback"
[2012-08-05 03:16:45] DBUG stats/modify_node_event update "global" clients (4)
[2012-08-05 03:16:45] DBUG client/worker 0x8ec1000 now has 5 clients
[2012-08-05 03:16:45] DBUG auth/auth_run_thread Authentication thread 3 started for /fallback
[2012-08-05 03:16:45] DBUG auth/auth_run_thread 1 client(s) pending on /fallback
[2012-08-05 03:16:45] DBUG auth_url/url_stream_end handler 3 sending request

i will downgrade for now

Maybe there is a bug when updating from KH3 to KH5:
When using JW-Player (a very commonly-used flashplayer, see link: http://www.longtailvideo.com/jw-player/) and Icecast233KH3, everything works fine. But when i use KH5 oder KH6 instead, mp3 streams won't start in the JW Player. You see only Buffering-messages, but the stream never stops.
Is there any idea where the problem comes from?

sdt105

i have 2 mounts configured

/stream & /fallback

/stream fallbacks in /fallback and also override it

and both have url auth

when there is a source in /fallback, but there is no source on /strea
admin/listmounts.xsl?mount=/stream shows as a 'mounted'm,
status.xsl & admin/stats.xsl shows /stream as active
but at listclients.xsl?mount=/stream it says 'mount does not exist'

im doing a script that gets stream information from a mount, or his fallbacks if there is no stream on it and using an custom xsl

<xsl:output omit-xml-declaration="no" method="xml" indent="yes" encoding="ISO-8859-1" />

<xsl:template match = "/icestats" >
    <xsl:for-each select="source">
    <ICECAST>
        <ONLINE>1</ONLINE>
        <LISTENERS><xsl:value-of select="listeners" /></LISTENERS>
        <TOP><xsl:value-of select="listener_peak" /></TOP>
        <GENRE><xsl:value-of select="genre" /></GENRE>
        <TITLE><xsl:value-of select="server_name" /></TITLE>
        <SONG><xsl:if test="artist"><xsl:value-of select="artist" /> - </xsl:if><xsl:value-of select="title" /></SONG>
    </ICECAST>
    </xsl:for-each>
</xsl:template>

i supposed that if there is a mount then there is a source on it so --> 1

is that a bug ? if not, how can i know if there is a source on a mount that is showing while /fallback has a a stream?

In order to allow more complex functions to run on on-(dis)connect we need the ability to pass arbitrary parameters to the commands specified in on-connect and on-disconnect

So instead of:

/usr/bin/foo

We need:

/usr/bin/foo param1 param2 param3

With the newest svn code (fallback patch reverted) I have a problem when using an authentication url generally: When looking into the icecast logs and using some debug logging on my handler url I found out that Icecast only calls the authentication url once for a client. If the client tries to reconnect the client will only get a 401 error (as seen in access log). It needs a longer time or a source reconnect until it works again.

Upgrade to 2.3.3-kh* appears to stop functioning

Most of the time when I receive a "Nothing received on" message, I receive it twice or more in the same second.

Eg:

[2012-07-08 17:42:14] WARN source/source_read Nothing received on /CFPW for 3 seconds
[2012-07-08 17:42:14] WARN source/source_read Nothing received on /CFPW for 3 seconds
[2012-07-08 17:42:14] WARN source/source_read Nothing received on /CFPW for 3 seconds

data saved in the log:
189.xxx.63.xxx - - [13/Jul/2012:18:55:00 -0300] "GET /live HTTP/1.1" 200 1411663 "http://stream.dddd.com.br/wm/player.swf" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/53" 217

data available in stats.xls

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11

It is not possible to obtain full details of the User, because the log saves only part of the agent

in 2.3.2 this is working.
in 2.3.2-kh31 - don't working :(
<relay>
<server>188.127.243.169</server>
<port>80</port>
<mount>/nashe-192</mount>
<local-mount>/nashe</local-mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
<mount>
<mount-name>/nashe</mount-name>
<charset>windows-1251</charset>
</mount>

in web name of song must be encoding from windows-1251 to utf-8...

i dont know what you did, but now the fast disconection -> conection on a mount point, is woking.... awsome...
before, if there was a endoder crash and after 0 second reconect, most of the times it said loging error, until the last listener ended the buffer on the mount point.
didnt know it was an issue :D TY!