Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-03-06T12:50:22Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/425http_proxy YP2018-03-06T12:50:22ZGitlab Bothttp_proxy YP```
Currently icecast2 only allows you to directly connect to the yp server(s), it
would be useful to me if there was a way to connect via a http proxy server.
``````
Currently icecast2 only allows you to directly connect to the yp server(s), it
would be useful to me if there was a way to connect via a http proxy server.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/429moveclients command problem2018-03-06T12:50:22Zvalen_23moveclients command problem```
In my ices configuration file, I have ices sending two streams to the same
icecast server (i.e. /eg1.ogg and /eg2.ogg). If I use the moveclients command
to move all the listeners from /eg1.ogg to /eg2.ogg, the listeners get garble...```
In my ices configuration file, I have ices sending two streams to the same
icecast server (i.e. /eg1.ogg and /eg2.ogg). If I use the moveclients command
to move all the listeners from /eg1.ogg to /eg2.ogg, the listeners get garbled
audio data. However, I am able to move listeners to a stream from a different
ices streamer without any problems. It's only when I try to move users to a
different stream from the same streamer do I get this problem.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/473Decoders quit after ~ 4 hours2018-03-06T12:50:22Zl.imminkDecoders quit after ~ 4 hours```
all vorbis based decoders close after listening to an icecast server (all
versions) after ~ 4 hours. I've tested ogg123, mplayer, foobar2000 and winamp,
with the icecast server on both a local system as on the internet. I've tested
o...```
all vorbis based decoders close after listening to an icecast server (all
versions) after ~ 4 hours. I've tested ogg123, mplayer, foobar2000 and winamp,
with the icecast server on both a local system as on the internet. I've tested
ogg123 with both the standard tcp/ip stack and netcat but all quit after ~ 4
hours. The decoders quit because they get an end of file request. In the icecast
server log the message DBUG format/format_generic_write_buf_to_client Client had
recoverable error -1 occurs. Still the server continues to play. After the
decoder is resetted it continues it normal operation.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/504Relayed streams not added to stream directories2018-03-06T12:50:22ZmarkRelayed streams not added to stream directories```
In my testing, relayed streams are not being added to the various stream
directories.
An additional minor problem is that current song of relayed streams does not
show up on the /status.xsl page.
``````
In my testing, relayed streams are not being added to the various stream
directories.
An additional minor problem is that current song of relayed streams does not
show up on the /status.xsl page.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/632Incorrect Base64 decoder in utils (missing '2018-03-06T12:50:22ZGitlab BotIncorrect Base64 decoder in utils (missing '*Base64 utils. Encode is ok, but decode? '=' is missed, so, VLC, that
contains correct base64 encoder, produces '=' at the end of the string.
We need to pacth that case in decoder:
char *util_base64_decode(unsigned char *input)
{
...*Base64 utils. Encode is ok, but decode? '=' is missed, so, VLC, that
contains correct base64 encoder, produces '=' at the end of the string.
We need to pacth that case in decoder:
char *util_base64_decode(unsigned char *input)
{
int len = strlen(input);
char *out = malloc(len*3/4 + 5);
char *result = out;
signed char vals[4];
while(len > 0) {
if(len < 4 && *input != '=')
{
free(result);
return NULL; /* Invalid Base64 data */
} else if (*input == '=') break;
Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/508YP can keep source tree read lock for too long2018-03-06T12:50:22ZKarl HeyesYP can keep source tree read lock for too long```
yp_touch keeps rlock on source tree when updating YP directory servers, if one
of the stated YP servers becomes inaccessible then curl will block for upto 30
seconds per server per source. Any new source connecting or disconnecting ...```
yp_touch keeps rlock on source tree when updating YP directory servers, if one
of the stated YP servers becomes inaccessible then curl will block for upto 30
seconds per server per source. Any new source connecting or disconnecting will
block on the wlock until the yp thread finishes all existing YP source updates.
Test with a listening port that does not send anything back.
```Ed "oddsock" ZaleskiEd "oddsock" Zaleskihttps://gitlab.xiph.org/xiph/icecast-server/-/issues/633Client count in stats.xml continues to increase.2018-03-06T12:50:22ZJoel EbelClient count in stats.xml continues to increase.In stats.xml, the <icestats><clients> value continually increases. Every time I restart a source, this number goes up and never comes back down. Right now it's up to 432 even though I have a 100 client limit. It seems that when a sour...In stats.xml, the <icestats><clients> value continually increases. Every time I restart a source, this number goes up and never comes back down. Right now it's up to 432 even though I have a 100 client limit. It seems that when a source disconnects, this client value doesn't decrement, but when a listening client disconnects it does. There could be more to it than that, but that's what it appears to be to me.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/509Logfile records "Eastern Standard Time" in date field, rather than GMT offset2018-03-06T12:50:22ZbazzymgLogfile records "Eastern Standard Time" in date field, rather than GMT offset```
In "access.log" logfile under IceCast2, the date field includes "Eastern
Standard Time" rather than an offset, such as "-400", as an Apache logfile
would. This produced errors in the Webalizer program under WinXP, and replacing
the ...```
In "access.log" logfile under IceCast2, the date field includes "Eastern
Standard Time" rather than an offset, such as "-400", as an Apache logfile
would. This produced errors in the Webalizer program under WinXP, and replacing
the field with "-400" removed the error.
I was told to post this by Mike Smith via the Icecast discussion list.
```Ed "oddsock" ZaleskiEd "oddsock" Zaleskihttps://gitlab.xiph.org/xiph/icecast-server/-/issues/640last character of playlist log is truncated2018-03-06T12:50:22Zbirbecklast character of playlist log is truncatedIn Icecast version 2.2.0 the last character of the playlist log is truncated.
In the function update_comments on line 252 of format_ogg.c the line is
len += strlen(artist) + strlen(title) + 3;
the line should read
len += strlen(art...In Icecast version 2.2.0 the last character of the playlist log is truncated.
In the function update_comments on line 252 of format_ogg.c the line is
len += strlen(artist) + strlen(title) + 3;
the line should read
len += strlen(artist) + strlen(title) + 4;
I have applied to patch to my source tree and the playlist log reads correctly.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/126icecast needs a buzzword compliant name.2018-03-06T12:50:22ZStan Seiberticecast needs a buzzword compliant name.```
icecast should be renamed to OpenStreamingXMLServerXP.
``````
icecast should be renamed to OpenStreamingXMLServerXP.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/524Encoding in status.xsl2018-03-06T12:50:22ZzverekEncoding in status.xsl```
The problem is: can't see right non-english (russian) id3 mp3 tags text in
status.xsl. fexed by adding `encoding="iso-8859-1"` in xsl:output tag. I've
been told it _shouldn't_ help, but it did. So probably there is a bug some
wher...```
The problem is: can't see right non-english (russian) id3 mp3 tags text in
status.xsl. fexed by adding `encoding="iso-8859-1"` in xsl:output tag. I've
been told it _shouldn't_ help, but it did. So probably there is a bug some
where..
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/195trouble running 'make' on RH 7.22018-03-06T12:50:21Zjoe.slagtrouble running 'make' on RH 7.2```
Following the directions in HACKING, I've run autogen.sh, configure, and make.
make dies with the following:
make[2]: Entering directory `/home/jslag/src/ice2/icecast/src'
gcc -DPACKAGE=\"icecast\" -DVERSION=\"2.0\" -DHAVE_DLFCN_H=...```
Following the directions in HACKING, I've run autogen.sh, configure, and make.
make dies with the following:
make[2]: Entering directory `/home/jslag/src/ice2/icecast/src'
gcc -DPACKAGE=\"icecast\" -DVERSION=\"2.0\" -DHAVE_DLFCN_H=1 -DHAVE_IPV6=1
-DSTDC_HEADERS=1 -DHAVE_STDINT_H=1 -DCHUID=1 -DCHROOT=1 -I. -I. -I./net
-I./thread -I./avl -I./httpp -I./log -I./timing -O20 -ffast-math
-fsigned-char -D_REENTRANT -D_GNU_SOURCE -I/usr/include/libxml2 -I/include
-I/include -c config.c
config.c:4:23: xmlmemory.h: No such file or directory
config.c:5:20: parser.h: No such file or directory
make[2]: *** [config.o] Error 1
make[2]: Leaving directory `/home/jslag/src/ice2/icecast/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jslag/src/ice2/icecast/src'
make: *** [all-recursive] Error 1
my /usr/include/libxml2/libxml directory includes
-rw-r--r-- 1 root root 4135 Apr 15 08:01 xmlmemory.h
-rw-r--r-- 1 root root 26902 Apr 15 08:01 parser.h
(and other stuff) from the stock RedHat 7.2 libxml2-devel-2.4.19-4.i386.rpm.
My caveman workaround to the problem was copying the files in question from
/usr/include/libxml2/libxml to /usr/include/libxml2, which worked. Presumably
there is a better solution.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/561Static files on demand problem2018-03-06T12:50:21ZGitlab BotStatic files on demand problem```
I've set up a Icecast2 server on my 800 AMD 256 ram PC. I have an ASDL-
connection (Telia, Sweden) and I'm behind a Netgear DG834G Router/Firewall with
port forwarding set up. The live streaming feature works just fine, but when i
...```
I've set up a Icecast2 server on my 800 AMD 256 ram PC. I have an ASDL-
connection (Telia, Sweden) and I'm behind a Netgear DG834G Router/Firewall with
port forwarding set up. The live streaming feature works just fine, but when i
try to make a playlist (http://smashitup.no-ip.org/music2.m3u) linking to
static content through the Icecast server I get an authentication prompt for
login/pass. I havent found anything in the official documentation about what to
do. I've solved the problem with Apache, but was asked to report the bug here.
In case you need more info about setup or whatever, just email me.
cheers
/jon
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/218Icecast 2.0 segfaults if already running on same port2018-03-06T12:50:21ZwsuffIcecast 2.0 segfaults if already running on same port```
Error was partly found via my error. Icecast2 was running from a prior session
on 8020. Unknowning to that I tryed to start it again w/ my only config which
uses port 8020
# ./icecast -c ../icecast.xml
Could not create listener socke...```
Error was partly found via my error. Icecast2 was running from a prior session
on 8020. Unknowning to that I tryed to start it again w/ my only config which
uses port 8020
# ./icecast -c ../icecast.xml
Could not create listener socket on port 8020
Changed groupid to 99.
Changed userid to 99.
Segmentation fault
Granted this isn't a major issue but couldn't it just terminate peacefully if
the listener socket is unavail
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/652Move clients to fallback when source disconnects2018-03-06T12:50:21ZTristanMove clients to fallback when source disconnectsCurrently, when a source disconnects, icecast2 appears to drop that mount's listening clients -- even if it has a fallback-mount defined. It would be nice if the existing clients were gracefully moved to the fallback instead of being di...Currently, when a source disconnects, icecast2 appears to drop that mount's listening clients -- even if it has a fallback-mount defined. It would be nice if the existing clients were gracefully moved to the fallback instead of being disconnected.
I know there's a mechanism to move clients, but I don't have prior knowledge of when the source will disconnect (ezstream is prone to SIGSEGV).Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/567Icecast2 W32 Forms Client -> Windows Service2018-03-06T12:50:21ZjasonrIcecast2 W32 Forms Client -> Windows Service```
I think it makes sense to run the Icecast2 server as a Windows Service in this
environment as opposed to my current workaround as having it run as an alway
logged-in underprivilaged account under terminal services on Windows Server...```
I think it makes sense to run the Icecast2 server as a Windows Service in this
environment as opposed to my current workaround as having it run as an alway
logged-in underprivilaged account under terminal services on Windows Server
2003.
Same goes for ezstream, of course. =)
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/227Final Linking needs different pthread parameter on OpenBSD2018-03-06T12:50:21ZgtgbrFinal Linking needs different pthread parameter on OpenBSD```
The last step when compiling Icecast2 from CVS under OpenBSD 3.1 fails with
ld: -lpthread: no
match
It works when using -pthread instead (I just went into the src directory and pasted the
corrected version of the last gcc commandl...```
The last step when compiling Icecast2 from CVS under OpenBSD 3.1 fails with
ld: -lpthread: no
match
It works when using -pthread instead (I just went into the src directory and pasted the
corrected version of the last gcc commandline to make it work).
This bug in the configure
script is known for a while, I just thought you guys might want it in Bugzilla (easier to remember
than "wasn't there some problem on some OS"). :)
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/656iceast-kh rev 9168 fails to compile in connection.c2018-03-06T12:50:21Zpadaniusiceast-kh rev 9168 fails to compile in connection.clatest revision of iceast-kh failes to compile (previous was OK) :
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -ffast-math -fsigned-char -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/include -pthread -g -O2 -c `test -f 'sighandle...latest revision of iceast-kh failes to compile (previous was OK) :
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -ffast-math -fsigned-char -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/include -pthread -g -O2 -c `test -f 'sighandler.c' || echo './'`sighandler.c
source='connection.c' object='connection.o' libtool=no \
depfile='.deps/connection.Po' tmpdepfile='.deps/connection.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -ffast-math -fsigned-char -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/include -pthread -g -O2 -c `test -f 'connection.c' || echo './'`connection.c
connection.c: In function `connection_complete_source':
connection.c:501: error: structure has no member named `con'
connection.c:502: error: structure has no member named `con'
connection.c:503: error: structure has no member named `parser'
connection.c:504: error: structure has no member named `parser'
make[3]: *** [connection.o] Error 1
make[3]: Leaving directory `/usr/src/icecast-kh/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/icecast-kh/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/icecast-kh'
make: *** [all] Error 2
Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/286authentication always fails if configure --prefix=/usr2018-03-06T12:50:21Zdoctorkaedingauthentication always fails if configure --prefix=/usr```
If 1.3.11 or 1.3.12 are compiled with --prefix=/usr, icecast always says "Bad
Password" when trying to give it an audio source with IceS or shout.
If compiled without --prefix=/usr, this behavior goes away.
``````
If 1.3.11 or 1.3.12 are compiled with --prefix=/usr, icecast always says "Bad
Password" when trying to give it an audio source with IceS or shout.
If compiled without --prefix=/usr, this behavior goes away.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/590Credits does not work2018-03-06T12:50:21ZGitlab BotCredits does not workHello
http://downloads.us.xiph.org/releases/icecast/icecast2_win32_2.2.0RC1_setup.exe
About -> Credits
does not work for me
WinXP Pro SP2 German;
AMD XP 2000+Hello
http://downloads.us.xiph.org/releases/icecast/icecast2_win32_2.2.0RC1_setup.exe
About -> Credits
does not work for me
WinXP Pro SP2 German;
AMD XP 2000+Michael SmithMichael Smith