Icecast Streaming Media Server

[fredux]

Hello,

I expericenced a problem on downloading an xml file for icecast config.

We use a wget method to download it but one of our mount point has a € on his name which corrupts the file. If I start icecast with this file, this is the result:

icecast2 -c icecast.xml
icecast.xml:32752: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xAC 0x50 0x48 0x64
<local-mount>/DJ-3t�PHdu31</local-mount>
^
FATAL: error parsing config file (icecast.xml)
XML config parsing error

This file must be downloaded every minutes, so I did this:

wget -O /home/icecast.xml http://...com/icecastconf.cfm?streamid=14 && iconv -f iso-8859-1 -t utf-8 /home/icecast.xml > /etc/icecast2/icecast.xml && killall -HUP icecast2

Somtimes, the system crashes and we loose a lot of our listeners. I did not know if it could be linked to this but once, I saw this message on log when it crashes:
EROR event/event_config_read Error parsing config, not replacing existing config
EROR event/event_config_read Parse error in reading /etc/icecast2/icecast.xml

Could it there a link between these error messages and the loose of our listeners ?

[karlH]

yes, you have to take care when placing non-ascii characters as data in xml, just like with special characters like & and <. The iconv conversion would seem correct (assuming iso-8859-1 is the originating charset). It's not clear what error is present based on your posting.

It's unlikely that a failed reading of the xml file is the cause of a server crash, it could be the trigger for it to happen but it's hard to say without more investigation, we don't even know which version you are using.

karl.

[fredux]

Sorry, yes, the version of icecast is 2.3.2-5.

I am not even sure that this is the cause of the crash, but several crashes happened at the time I could see these errors on the log, that is why I was wondering.

Is this killall -HUP ok ? Is /etc/init.d/icecast2 reload better ?

I do not know where to go to investigate more in fact. Should I receive more relevant infos if I increase the logs (do not like that when it is under production)

<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<!-- <playlistlog>playlist.log</playlistlog> -->
<loglevel>1</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
<logsize>1000000</logsize> <!-- Max size of a logfile -->
<!-- If logarchive is enabled (1), then when logsize is reached
the logfile will be moved to [error|access|playlist].log.DATESTAMP,
otherwise it will be moved to [error|access|playlist].log.old.
Default is non-archive mode (i.e. overwrite)
-->
<logarchive>1</logarchive>
</logging>

This is other informations about our configuration:

<icecast>
<limits>
<clients>5000</clients>
<sources>5000</sources>
<threadpool>5</threadpool>
<queue-size>100028</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>65535</burst-size>
</limits>

<authentication>
<source-password>12345678</source-password>
<relay-password>12345678</relay-password>
<admin-user>admin</admin-user>
<admin-password>****</admin-password>
</authentication>


<hostname>streaming.****.com</hostname>
<listen-socket>
<port>8000</port>
</listen-socket>

<listen-socket>
<port>80</port>
</listen-socket>

<directory>
<yp-url-timeout>15</yp-url-timeout>
<yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
</directory>
<directory>
<yp-url-timeout>15</yp-url-timeout>
<yp-url>http://www.oddsock.org/cgi-bin/yp-cgi</yp-url>
</directory>


<relay>
<server>player.*****.com</server>

<port>8080</port>
<mount>/flux-28200</mount>
<local-mount>/DJSiran-Tamil-FM</local-mount>
<on-demand>1</on-demand>
</relay>
....

I am just beginner under icecast

[karlH]

HUP should be fine, I'm unsure if that script has reload performing a HUP signal as it's not one of ours.

I can't say what the problem could be as the version you have looks to be from a distribution so the changes to 2.3.2 are not known but if you want to try the trunk code (source trees at http://people.xiph.org/~brendan/snapshots) then we could investigate any issue further.

karl.

[fredux]

Yesterday, at 21.00, icecast crashes. What makes me think that there is a problem with the method of fetching the file is that I saw this on the log:

78.42.100.82 - - [01/Feb/2010:21:08:33 +0100] "GET /ParisChanson/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@/2010:00:08:54 +0100] "GET /ParisChanson/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
78.34.12.152 - - [31/Jan/2010:00:08:54 +0100] "GET /ParisChanson/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
84.166.16.241 - - [31/Jan/2010:00:08:55 +0100] "GET /ParisChanson/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0
87.174.143.238 - - [31/Jan/2010:00:08:55 +0100] "GET /Laid-Back-Radio/index.html HTTP/1.0" 404 106 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" 0

It seems as if the conversion of the file icecasts.xml did not happen well or am I wrong ? What these lines could mean under icecast access logs, isn't it a problem on configuration file ?