Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-10-04T11:08:04Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2126listener_remove is not triggered when kicking users2018-10-04T11:08:04ZMarius Flagelistener_remove is not triggered when kicking usersWhen kicking users, listener_remove isn't triggered. This has been tested on Icecast 2.3.3.
I haven't tested if this works if you remove a mount point, but one would like the same functionality here, that listener_remove is triggered as...When kicking users, listener_remove isn't triggered. This has been tested on Icecast 2.3.3.
I haven't tested if this works if you remove a mount point, but one would like the same functionality here, that listener_remove is triggered as well. I use these triggers to update a database with listeners and to make sure I have consistency, it would be nice if both triggers (listener_add and listener_remove) were triggered whatever causes a listener to be added and removed.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2125Kicking a source disconnects listeners even if fallback defined2018-03-06T12:49:47ZThomas B. RückerKicking a source disconnects listeners even if fallback definedAs mentioned by ph3-der-loewe, this seems to happen. One would expect that if a source is forcefully disconnected, that the listeners are sent to defined fallbacks.As mentioned by ph3-der-loewe, this seems to happen. One would expect that if a source is forcefully disconnected, that the listeners are sent to defined fallbacks.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2112Locks on avl client_trees needed?2020-10-11T11:18:30ZMarvin ScholzLocks on avl client_trees needed?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2037Check if Icecast returns HTTP 200 on disallowed metadata updates2018-03-06T12:49:47ZThomas B. RückerCheck if Icecast returns HTTP 200 on disallowed metadata updatesWe've had a report that some version of Icecast might be doing this.
http://lists.xiph.org/pipermail/icecast/2014-August/012905.html
We should check if this is the case and if so consider changing it to a 403, accompanied by a sensible ...We've had a report that some version of Icecast might be doing this.
http://lists.xiph.org/pipermail/icecast/2014-August/012905.html
We should check if this is the case and if so consider changing it to a 403, accompanied by a sensible error message.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2031Admin functions do not accept URL encoded values2018-03-06T12:49:47ZBradAdmin functions do not accept URL encoded valuesThe admin functions should accept/decode the mount GET value since / is a reserved character.
This works:
http://192.168.1.10:8000/admin/metadata?mount=/mystream&mode=updinfo&song=ACDC+Back+In+Black
This doesn't:
http://192.168.1.10:80...The admin functions should accept/decode the mount GET value since / is a reserved character.
This works:
http://192.168.1.10:8000/admin/metadata?mount=/mystream&mode=updinfo&song=ACDC+Back+In+Black
This doesn't:
http://192.168.1.10:8000/admin/metadata?mount=%F2mystream&mode=updinfo&song=ACDC+Back+In+Black
Response is: 400 - Source does not exist
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1271missing comprehensive list of configuration directives2018-03-06T12:49:48Zmuellimissing comprehensive list of configuration directivesI just wanted to lookup the semantic of a configuration directive and couldn't find it easily. A comprehensive list like on http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives would be nice.I just wanted to lookup the semantic of a configuration directive and couldn't find it easily. A comprehensive list like on http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives would be nice.Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/934[PATCH] Change configuration file in Win32 Service2018-03-06T12:49:48Zkiwicasio[PATCH] Change configuration file in Win32 ServiceI think it can be interesting to add possibiliy to change the location (and name) of configuration file wich is currently hardcoded in source code.
actually :
;-------------------------
int argc2 = 3;
char* argv2[3];
argv2[0] = ...I think it can be interesting to add possibiliy to change the location (and name) of configuration file wich is currently hardcoded in source code.
actually :
;-------------------------
int argc2 = 3;
char* argv2[3];
argv2[0] = "icecastService.exe";
argv2[1] = "-c";
argv2[2] = "icecast.xml";
int ret = mainService(argc2, (char **)argv2);
;-------------------------
I think this is not efficient :/
thank's in advance...https://gitlab.xiph.org/xiph/icecast-server/-/issues/798Nothing appears on icecast when i'm broadcasting2018-03-06T12:49:49ZdeepbluesensationsNothing appears on icecast when i'm broadcastingHello there,
My server is saying that i'm broadcasting, but i find no traces of my program on icecast at my usual page, then nobody can listen to my program...
grrrr
The SmurfHello there,
My server is saying that i'm broadcasting, but i find no traces of my program on icecast at my usual page, then nobody can listen to my program...
grrrr
The SmurfMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/774YP data submitted even when source cannot connect2018-03-06T12:49:49Zchris.aretiYP data submitted even when source cannot connectHi,
I'm using 2.3.0 but as I didn't see it as a bugfix on the list, I'm presuming it remains the same in 2.3.1..
I have icecast set to not allow people to take over source control if someone's connected already, however due to necessit...Hi,
I'm using 2.3.0 but as I didn't see it as a bugfix on the list, I'm presuming it remains the same in 2.3.1..
I have icecast set to not allow people to take over source control if someone's connected already, however due to necessity when some people kill the connected source and broadcast - the main broadcast server still attempts to connect to the source every 15 seconds. This means that when the DJ has finished their set, then simply disconnect and 24 hour playout comes back online.
However, I've noticed with 2.3.0 that even though the broadcast server gets a disconnected error message, the metadata the broadcast server generates whilst the other source is on air manages to update and overwrite that which the current source connection is providing.
In short, metadata from a connecting client (who cannot connect because the source is in use by another client) still manages to be accepted by icecast and updated on the stream.. meaning that the two clients are constantly fighting to keep metadata with that of the current source.
Any help would be much appreciated!
Thanks,
Chris.Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/642Fallback overrides when it shouldn't2021-01-29T10:17:57ZGitlab BotFallback overrides when it shouldn'tI have a server with two mounts which have the same fallback mount.
Actually, I have three mounts, with one having a second as its fallback
and that second having the common fallback. But you get the idea.
All these mounts have fallbac...I have a server with two mounts which have the same fallback mount.
Actually, I have three mounts, with one having a second as its fallback
and that second having the common fallback. But you get the idea.
All these mounts have fallback-override set.
The problem is that if I connect to any of the mounts for which the
fallback mount is configured, all mounts currently falling back to that
mount will be pulled forward to the connecting stream, not just listeners
who tuned in via the connected mount.
Example. A and B are configured to fall back to C. Listeners tune into
both A and B when neither is connected and drop through to C. A source
connects to B. All listeners through both A and B are pulled forward to B.
This only affects listeners tuned in at the time the source connects.
Using the above example, anyone tuning into A after B connects will still
get C.
This is using Icecast 2.2 compiled from source on Debian 3.0.Icecast 2.3Michael SmithMichael Smithhttps://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/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 Moffitt