similar to: Icecast Digest, Vol 175, Issue 11

Hi Thanks for the reply > >> >> Set logging to verbose, starts Icecast, have it running for a while and >> then >> provide us with the error log please. >> >> Chances are your beta lacks cURL. Where did you get the beta from? >> >> On 27 Jan 2019, at 11:33, Damian wrote: >> > > > I installed from source using the tarball

Hi, This thread seems to have stalled. Would anyone still be able to help me with this one? I?ve posted my log as requested. Any advice would be a great help. > > Message: 1 > Date: Tue, 29 Jan 2019 20:00:21 +1000 > From: Damian <db76 at riseup.net> > To: icecast at xiph.org > Subject: Re: [Icecast] Icecast Digest, Vol 175, Issue 11 > Message-ID:

Hi, I apologise if this has been raised before. I’m finding that with the below settings enabled in my icecast.xml file, YP directory listings work for me when using icecast 2.4.4 but listings aren’t working for me with the same config settings in version 2.5. <directory> <yp-url-timeout>15</yp-url-timeout>

Hello, In order to identify if was some issue regard to the auth api we include some trace logs and we move it to other machine. Bellow is what trace we are generating (date, result, elapsed time in milleseconds, request): [8/29/18 11:49:00 AM] 200 0.3721 action=listener_add&server=r22&port=443&client=2616&mount=/alphafmsp&user=&p

I'm having an issue with URL-based authentication on Windows Server that is being aggravated by a separate logging issue. In the server's error log: [2020-03-13 16:59:46] DBUG connection/connection.c alias has made /player/ > into /player/index.html > [2020-03-13 16:59:46] INFO auth/auth.c adding client for authentication > [2020-03-13 16:59:46] DBUG auth/auth.c ...refcount

So, I’ll try to explain what I mean a little more by referring to some images. In the first image here, http://systrum.net/mount.png <http://systrum.net/mount.png> iTunes shows the mount-name of my stream. This is not the option that I want, but it is what seems to be the default that I am stuck with. In this second image, http://systrum.net/stream.png <http://systrum.net/stream.png>

Hi, needing some advice. I am running a backports version of icecast for Debian 10. I have found that with this version, the icecast server will usually run for about 7 days before it crashes. I found in the syslog that icecast gets terminated because it?s 'out of memory'. This never happened on the standard (stable) version of icecast that I ran on Debian 9 installed via apt. I?ve added

Good morning, first of all, thank you for your nice report. :) On Sat, 2020-10-10 at 20:32 +1000, Damian wrote: > Hi, needing some advice. > I am running a backports version of icecast for Debian 10. I have > found that with this version, the icecast server will usually run for > about 7 days before it crashes. I found in the syslog that icecast > gets terminated because it?s

Hi Philipp, Edit (apologies for the repeated emails) Thanks for the quick response. I’ve run the command and you can find the output by following this link https://systrum.net/output.txt <https://systrum.net/output.txt> I'm running icecast with SSL enabled. I needed a a version of Icecast with SSL support which is why I am using the backports version. Regards Damian -------------- next

Hi, I have been digging through the icecast mailing list archives trying to find out the meaning of this recurring message in my error.log [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong request type from client [2018-05-01 19:50:16] EROR connection/_handle_connection Wrong request type from client [2018-05-01 19:50:16] INFO source/source_main listener count on /Systrum now 1

Thanks for clarifying that Philipp. Yeah, I compared the time stamps in the error.log and access.log (below) and saw the corresponding HEAD requests. I've been getting a lot of these so I thought that there was something I could do to allow these clients to connect to the stream. I guess I just need to ignore them. Thanks Damian Snippet from error.log [2018-05-04 00:28:17] EROR

Hi, AFAIK, icecast only supports specific HTTP request methods (GET for listeners, PUT/SOURCE for sources). This message is logged when a client uses an unsupported request method (such as HEAD or POST). Please note that this might be inaccurate, but I saw this kind of logs during a development that involved unsupported request methods. ? Teddy Le 2018-05-01 13:00, Damian a ?crit?: >

Thanks for the reply. So then does this message indicate an issue with my setup (I use Liquidsoap to stream to Icecast) or an issue with a listener client? It looks like the listener count drops immediately after someone connects which to seems like a problem at the listeners end. > On 2 May 2018, at 22:00, icecast-request at xiph.org wrote: > > Send Icecast mailing list submissions to

Good morning, On Sun, 2020-10-11 at 10:24 +1000, Damian wrote: > Can I also ask, which is the recommended course of action? Sure, just keep in mind that we had weekend, so people were off. ;) > Should I rebuild icecast with OpenSSL or is there now a fixed version > via backports that I can use? Based on... On Sat, 2020-10-10 at 23:06 +1000, Damian wrote: > Edit (apologies for the

I'd like to commit the following patch which adds a new option to the htpasswd client authenticator. This option <option name="allow_duplicate_users"> specifies wether or not the same username can connect to a mountpoint more than once. This is pretty much a required feature for any decent use of the listener authentication capabilities of icecast. thoughts ? comments ?

Hi, I am currently running Icecast 2.4.4 on Debian stretch and am using the info from the status-json.xsl to display some stats on my radio webpage. This works well. On the same website, I have also managed to display listener stats. I looks like this https://systrum.net/listeners.png To get this data, my developer created a php script containing the icecast admin credentials so that I can

Hello, We believe we have found a bug in Icecast in version 2.3.2 (not the the released code but a version that was taken from a tag icecast2-svn-20090324.tar.gz) and it looks that it also affects the last version in the trunk. We studied a core dump generated by icecast. We found that the crash occurred in the following icecast code: static void auth_remove_listener (auth_t *auth,

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

hallo firstly sorry for posting to wrong thread i want to ask if somebody could explain meaning of log records below DBUG stats/modify_node_event update global connections (686) DBUG stats/modify_node_event update global client_connections (685) number in parentheeses is increasing in every log line what is menaing of this number? because this number goes over 59669 and it seems that after

Hello, I found a fallback trouble on icecast 2.1kh4 (but it's the same with 2.0 I think) : - ices streams live.ogg to icecast - icecast has a fallback live-default.ogg for live.ogg - a listener A listen at live.ogg - I shut down the source - the listener A is trying to read data from its connection, but receives nothing. Sometimes, it gets fallback data, sometimes nothing... (source