similar to: Icecast crashing / terminated - out of memory

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

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

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

Hi, I installed from source using the tarball on the liquidsoap website. I installed curl as a prerequisite before building icecast from source. A version check shows that I have the current version of curl as follows: curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52. The first part of the log shows that YP server handling is disabled though. (I pasted a fuller snippet of the log earlier but it’s

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

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

Hello List, I have a problem with the client Roundcube. Whenever I save a draft to the Folder INBOX.Drafts a old mail in my INBOX will be marked as unread. Here are the IMAP Logs from Roundcube and Dovecot debug logs. I have no idea why it happens. The IMAP protocol looks normal to me but as you can see in the second to last line in the Dovecot log Dovecot is changing the flag of an old E-Mail

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>

According to the manual, system() splits output lines into 8096-char chunks; under UNIX, actually seems to return 8094 chars, and drop the 8095th. Spot missing digits in: x2 <- system("perl -e 'print \"0123456789\"x10000'", intern=T) Looks like a bug in the code to remove newlines at src/unix/sys-unix.c:218 -- fgets() reads size-1 characters and adds

Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able to be rescheduled within napi_complete_done() even in non-busypoll case, but virtnet_poll() always enabled interrupts before complete, and when napi was rescheduled within napi_complete_done() it did not disable interrupts. This caused more interrupts when event idx is disabled. According to commit cbdadbbf0c79

Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able to be rescheduled within napi_complete_done() even in non-busypoll case, but virtnet_poll() always enabled interrupts before complete, and when napi was rescheduled within napi_complete_done() it did not disable interrupts. This caused more interrupts when event idx is disabled. According to commit cbdadbbf0c79

On Thu, Dec 07, 2017 at 01:15:15PM +0900, Toshiaki Makita wrote: > Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able > to be rescheduled within napi_complete_done() even in non-busypoll case, > but virtnet_poll() always enabled interrupts before complete, and when > napi was rescheduled within napi_complete_done() it did not disable > interrupts. >

On 2017?12?07? 13:09, Michael S. Tsirkin wrote: > On Thu, Dec 07, 2017 at 01:15:15PM +0900, Toshiaki Makita wrote: >> Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able >> to be rescheduled within napi_complete_done() even in non-busypoll case, >> but virtnet_poll() always enabled interrupts before complete, and when >> napi was rescheduled

On 2017?12?07? 13:09, Michael S. Tsirkin wrote: > On Thu, Dec 07, 2017 at 01:15:15PM +0900, Toshiaki Makita wrote: >> Since commit 39e6c8208d7b ("net: solve a NAPI race") napi has been able >> to be rescheduled within napi_complete_done() even in non-busypoll case, >> but virtnet_poll() always enabled interrupts before complete, and when >> napi was rescheduled