From rlbart53 at gmail.com Thu Oct 14 12:49:03 2021 From: rlbart53 at gmail.com (Richard Bartholomew) Date: Thu, 14 Oct 2021 13:49:03 +0100 Subject: [Icecast] BINDING PORT NUMBER TO MOUNTPOINT Message-ID: <020f01d7c0f9$de3df0f0$9ab9d2d0$@gmail.com> Hi, Basically, is this possible, please? I have a number of port numbers and mount points defined to cater for a live stream and a test environment. It appears that I can connect to Icecast and start streaming music to any of the opened ports provided I supply the correct mountpoint and password combination. This means that, however unlikely, a presenter could connect to our live server rather than our test one by accident! Therefore, can a mountpoint be bound to a specific port number to avoid this possibility, please? Thanks for any help. Regards Richard Bartholomew -------------- next part -------------- An HTML attachment was scrubbed... URL: From epirat07 at gmail.com Thu Oct 14 12:52:24 2021 From: epirat07 at gmail.com (Marvin Scholz) Date: Thu, 14 Oct 2021 14:52:24 +0200 Subject: [Icecast] BINDING PORT NUMBER TO MOUNTPOINT In-Reply-To: <020f01d7c0f9$de3df0f0$9ab9d2d0$@gmail.com> References: <020f01d7c0f9$de3df0f0$9ab9d2d0$@gmail.com> Message-ID: On 14 Oct 2021, at 14:49, Richard Bartholomew wrote: > Hi, > > > > Basically, is this possible, please? > > > > I have a number of port numbers and mount points defined to cater for > a live > stream and a test environment. > > > > It appears that I can connect to Icecast and start streaming music to > any of > the opened ports provided I supply the correct mountpoint and password > combination. This means that, however unlikely, a presenter could > connect > to our live server rather than our test one by accident! > > > > Therefore, can a mountpoint be bound to a specific port number to > avoid this > possibility, please? > No, this is not possible. Usually for such a setup I would recommend to just use two different instances of Icecast. > > > Thanks for any help. > > > > Regards > > Richard Bartholomew > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From mph at emotrics.com Thu Oct 14 17:22:35 2021 From: mph at emotrics.com (Milton Huang) Date: Thu, 14 Oct 2021 10:22:35 -0700 Subject: [Icecast] Client has fallen too far behind Message-ID: I'm new to Icecast and this mailing list. I have set it up to run a continuous (unending) audio stream that is being generated by a Python script. In my log I found an entry that said: [2021-09-17 06:03:53] INFO source/send_to_listener Client 620 (XX.XX.XX.XXX) has fallen too far behind, removing The user gets kicked, and the listener count decreases. What does this mean? Is the client pausing too long or getting out of sync somehow? What is the best way for me to learn what is happening, and how to prevent it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From madsend at morningside.edu Thu Oct 14 17:52:16 2021 From: madsend at morningside.edu (Dave Madsen) Date: Thu, 14 Oct 2021 12:52:16 -0500 Subject: [Icecast] unsubscribe Message-ID: <6a423105ada6680ac56cf0031082c5b4@mail.gmail.com> *Dave Madsen* Associate Professor & Dept. Head Mass Communication _____ *Morningside University* 1501 Morningside Ave. Sioux City, IA 51106 o: 712-274-5480 *|* m: 712-490-3327 *| *morningside.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From epirat07 at gmail.com Thu Oct 14 18:19:28 2021 From: epirat07 at gmail.com (Marvin Scholz) Date: Thu, 14 Oct 2021 20:19:28 +0200 Subject: [Icecast] Client has fallen too far behind In-Reply-To: References: Message-ID: <4B4FE989-E9E1-4B33-A6B0-FB7EC360598C@gmail.com> On 14 Oct 2021, at 19:22, Milton Huang wrote: > I'm new to Icecast and this mailing list. I have set it up to run a > continuous (unending) audio stream that is being generated by a Python > script. In my log I found an entry that said: > > [2021-09-17 06:03:53] INFO source/send_to_listener Client 620 > (XX.XX.XX.XXX) has fallen too far behind, removing > > The user gets kicked, and the listener count decreases. > > What does this mean? Is the client pausing too long or getting out of > sync > somehow? Hi, clients falling behind can have various reasons. Generally it means that the listener client is at the end of Icecasts buffer, the size of which is configured with the queue-size option in the icecast.xml. One reason for the client falling behind could be that the client is on a slow network connection and can therefore not keep up with the live stream. Depending on how the client is implemented, it could be that it indeed does not handle pausing properly, though with most clients that shouldn't be an issue anymore. Yet another although rarer reason could be that you are streaming with a very high bandwidth, like for a video stream and did not adjust the buffer to be large enough. > What is the best way for me to learn what is happening, and how to > prevent > it? There is not much you can do about without knowing exactly the reason why the specific client disconnected. And even then, as described above might be just a slow network connection. Seeing these messages about a client being dropped is not that unusual. However if you can reproduce this with your listener client, then you should check the logs of the client > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From ross at stationplaylist.com Fri Oct 15 00:28:56 2021 From: ross at stationplaylist.com (Ross Levis) Date: Fri, 15 Oct 2021 13:28:56 +1300 Subject: [Icecast] Client has fallen too far behind In-Reply-To: <4B4FE989-E9E1-4B33-A6B0-FB7EC360598C@gmail.com> References: <4B4FE989-E9E1-4B33-A6B0-FB7EC360598C@gmail.com> Message-ID: <00a301d7c15b$a59db5c0$f0d92140$@com> Another possible reason is the speed of the encoding is different to the speed of the playback device. Hardware soundcard chips are often responsible for the speed of encoding and playback, and these are not 100% accurate. Although more accurate than computer clocks. We have an Icecast stream being played by a dedicated playback device used for a studio to transmitter link, and it gets further and further behind over several days or weeks of continuous play. Occasionally there is a pause when Icecast drops the stream and the device reconnects. This is on a local network so not related to bandwidth issues. For others, the opposite is also possible where the playback device is playing slightly slower than the encoder and the playback buffer eventually gets full and the playback device has to drop some audio causing a short skip. -----Original Message----- From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Marvin Scholz Sent: Friday, 15 October 2021 7:19 am To: Icecast streaming server user discussions Subject: Re: [Icecast] Client has fallen too far behind On 14 Oct 2021, at 19:22, Milton Huang wrote: > I'm new to Icecast and this mailing list. I have set it up to run a > continuous (unending) audio stream that is being generated by a Python > script. In my log I found an entry that said: > > [2021-09-17 06:03:53] INFO source/send_to_listener Client 620 > (XX.XX.XX.XXX) has fallen too far behind, removing > > The user gets kicked, and the listener count decreases. > > What does this mean? Is the client pausing too long or getting out of > sync > somehow? Hi, clients falling behind can have various reasons. Generally it means that the listener client is at the end of Icecasts buffer, the size of which is configured with the queue-size option in the icecast.xml. One reason for the client falling behind could be that the client is on a slow network connection and can therefore not keep up with the live stream. Depending on how the client is implemented, it could be that it indeed does not handle pausing properly, though with most clients that shouldn't be an issue anymore. Yet another although rarer reason could be that you are streaming with a very high bandwidth, like for a video stream and did not adjust the buffer to be large enough. > What is the best way for me to learn what is happening, and how to > prevent > it? There is not much you can do about without knowing exactly the reason why the specific client disconnected. And even then, as described above might be just a slow network connection. Seeing these messages about a client being dropped is not that unusual. However if you can reproduce this with your listener client, then you should check the logs of the client > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast _______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast From mail at psychedelik.com Wed Oct 20 17:02:45 2021 From: mail at psychedelik.com (mail at psychedelik.com) Date: Wed, 20 Oct 2021 19:02:45 +0200 Subject: [Icecast] Remove please Message-ID: <9706bc877d7b8274e712667305edd755@psychedelik.com> From dik23 at hotmail.com Thu Oct 21 17:49:05 2021 From: dik23 at hotmail.com (Dik ....) Date: Thu, 21 Oct 2021 17:49:05 +0000 Subject: [Icecast] Single input to multiple outputs with different fallbacks Message-ID: I have an input mount /input that butt connects to I have 2 fallback mounts /fallback1 and /fallback2 What I want is for the input to feed 2 outputs one of which that falls back to /fallback1 and the other to /fallback2 Is this possible with icecast? Is it possible to use relays or aliases to achieve this? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Fri Oct 22 08:16:08 2021 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Fri, 22 Oct 2021 08:16:08 +0000 Subject: [Icecast] Single input to multiple outputs with different fallbacks In-Reply-To: References: Message-ID: <7b6c98da13e39569ed1d8c5217d1bdb109a4bb49.camel@de.loewenfelsen.net> Good morning, On Thu, 2021-10-21 at 17:49 +0000, Dik .... wrote: > I have an input mount /input that butt connects to > > I have 2 fallback mounts /fallback1 and /fallback2 > > What I want is for the input to feed 2 outputs one of which that > falls back to /fallback1 and the other to /fallback2 > > Is this possible with icecast? Is it possible to use relays or > aliases to achieve this? As you already guessed this is perfectly possible with relays. A block similar to this could be used: 127.0.0.1 8000 /fallback1 /fallback2 Please also check the docs on to see which exact options will work for you. With best regards, -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From db76 at riseup.net Sat Oct 23 06:15:19 2021 From: db76 at riseup.net (db76 at riseup.net) Date: Sat, 23 Oct 2021 16:15:19 +1000 Subject: [Icecast] Preventing connections from unknown user agents Message-ID: <803DF452-C12D-4FBF-86DE-E93BB3BD6A3E@riseup.net> Hi, I?m hoping for some advice on keeping away unwanted connections to the server. I have streams on two mount points that are receiving connections from a number of users that have an ?unknown? user agent. Sometimes I get these types of connections on both mount points simultaneously from the same IP which leads me to believe that they?re not legitimate listeners - perhaps a bot, ripper, or metadata leech. I already have a script that kicks any user that connects to both mount points simultaneously from the same IP address. However, I?d like to know I if it might help if I added the following lines in a robots.txt file? User-Agent: * Allow: / User-agent: unknown Disallow: / I don?t currently have a robots.txt set up. If this won?t help, can anyone suggest a better way to prevent such connections? Thanks Damian -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgalt at gmx.net Sat Oct 23 18:24:39 2021 From: hgalt at gmx.net (HGAlt) Date: Sat, 23 Oct 2021 20:24:39 +0200 Subject: [Icecast] Preventing connections from unknown user agents In-Reply-To: <803DF452-C12D-4FBF-86DE-E93BB3BD6A3E@riseup.net> References: <803DF452-C12D-4FBF-86DE-E93BB3BD6A3E@riseup.net> Message-ID: <001b01d7c83b$3e64d460$bb2e7d20$@gmx.net> I Domian, sorry I cannot answer your question. But I would like to point out, that I have also some IPs which try to connect to my Icecast streamer with an empty user agent. But also with known user agents, which try to connect for 7/24. I don?t allow them to connect. One is retrying it almost every minute. Anybody know what is behind that? Thanks, Hans-Georg Von: Icecast [mailto:icecast-bounces at xiph.org] Im Auftrag von db76 at riseup.net Gesendet: Samstag, 23. Oktober 2021 08:15 An: icecast at xiph.org Betreff: [Icecast] Preventing connections from unknown user agents Hi, I?m hoping for some advice on keeping away unwanted connections to the server. I have streams on two mount points that are receiving connections from a number of users that have an ?unknown? user agent. Sometimes I get these types of connections on both mount points simultaneously from the same IP which leads me to believe that they?re not legitimate listeners - perhaps a bot, ripper, or metadata leech. I already have a script that kicks any user that connects to both mount points simultaneously from the same IP address. However, I?d like to know I if it might help if I added the following lines in a robots.txt file? User-Agent: * Allow: / User-agent: unknown Disallow: / I don?t currently have a robots.txt set up. If this won?t help, can anyone suggest a better way to prevent such connections? Thanks Damian -- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From mph at emotrics.com Sat Oct 23 18:22:13 2021 From: mph at emotrics.com (Milton Huang) Date: Sat, 23 Oct 2021 11:22:13 -0700 Subject: [Icecast] Client has fallen too far behind In-Reply-To: <00a301d7c15b$a59db5c0$f0d92140$@com> References: <4B4FE989-E9E1-4B33-A6B0-FB7EC360598C@gmail.com> <00a301d7c15b$a59db5c0$f0d92140$@com> Message-ID: Thanks for the input. It helps a lot. I've got a stream I'm continuously generating from a server, and our team is planning to build a mobile app to access and play it. Your comments are getting me to think about what type of monitoring we want to put on the client end, especially since we want the stream to be constantly 'live' (i.e. the users can't pause the stream - they can only rejoin the current stream so that everyone is listening to the same thing as close as possible given network connection limitations). I'm sure I'll have a lot more questions as we try to ramp up and add relays and distribute our signal to distant locations! On Thu, Oct 14, 2021 at 5:28 PM Ross Levis wrote: > Another possible reason is the speed of the encoding is different to the > speed of the playback device. Hardware soundcard chips are > often responsible for the speed of encoding and playback, and these are > not 100% accurate. Although more accurate than computer > clocks. > > We have an Icecast stream being played by a dedicated playback device used > for a studio to transmitter link, and it gets further and > further behind over several days or weeks of continuous play. Occasionally > there is a pause when Icecast drops the stream and the > device reconnects. This is on a local network so not related to bandwidth > issues. > > For others, the opposite is also possible where the playback device is > playing slightly slower than the encoder and the playback > buffer eventually gets full and the playback device has to drop some audio > causing a short skip. > > -----Original Message----- > From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Marvin Scholz > Sent: Friday, 15 October 2021 7:19 am > To: Icecast streaming server user discussions > Subject: Re: [Icecast] Client has fallen too far behind > > > > On 14 Oct 2021, at 19:22, Milton Huang wrote: > > > I'm new to Icecast and this mailing list. I have set it up to run a > > continuous (unending) audio stream that is being generated by a Python > > script. In my log I found an entry that said: > > > > [2021-09-17 06:03:53] INFO source/send_to_listener Client 620 > > (XX.XX.XX.XXX) has fallen too far behind, removing > > > > The user gets kicked, and the listener count decreases. > > > > What does this mean? Is the client pausing too long or getting out of > > sync > > somehow? > > Hi, > > clients falling behind can have various reasons. Generally it means that > the listener client is at the end of Icecasts buffer, the size of which > is > configured with the queue-size option in the icecast.xml. > > One reason for the client falling behind could be that the client is on > a slow network connection and can therefore not keep up with the live > stream. > > Depending on how the client is implemented, it could be that it indeed > does not handle pausing properly, though with most clients that > shouldn't > be an issue anymore. > > Yet another although rarer reason could be that you are streaming with a > very > high bandwidth, like for a video stream and did not adjust the buffer to > be large enough. > > > What is the best way for me to learn what is happening, and how to > > prevent > > it? > > There is not much you can do about without knowing exactly the reason > why > the specific client disconnected. And even then, as described above > might > be just a slow network connection. Seeing these messages about a client > being dropped is not that unusual. > > However if you can reproduce this with your listener client, then you > should check > the logs of the client > > > _______________________________________________ > > Icecast mailing list > > Icecast at xiph.org > > http://lists.xiph.org/mailman/listinfo/icecast > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yahav.shasha at gmail.com Sat Oct 23 19:04:52 2021 From: yahav.shasha at gmail.com (Yahav Shasha) Date: Sat, 23 Oct 2021 22:04:52 +0300 Subject: [Icecast] Preventing connections from unknown user agents In-Reply-To: <803DF452-C12D-4FBF-86DE-E93BB3BD6A3E@riseup.net> References: <803DF452-C12D-4FBF-86DE-E93BB3BD6A3E@riseup.net> Message-ID: I think 'listener_add' (url listener auth) is your best option besides modifying icecast itself: https://icecast.org/docs/icecast-latest/auth.html ?????? ???, 23 ????? 2021, 09:20, ??? ?: > Hi, > > > I?m hoping for some advice on keeping away unwanted connections to the > server. > > > I have streams on two mount points that are receiving connections from a > number of users that have an ?unknown? user agent. Sometimes I get these > types of connections on both mount points simultaneously from the same IP > which leads me to believe that they?re not legitimate listeners - perhaps a > bot, ripper, or metadata leech. > > > I already have a script that kicks any user that connects to both mount > points simultaneously from the same IP address. However, I?d like to know I > if it might help if I added the following lines in a robots.txt file? > > > User-Agent: * > > Allow: / > > > User-agent: unknown > > Disallow: / > > > I don?t currently have a robots.txt set up. If this won?t help, can anyone > suggest a better way to prevent such connections? > > > Thanks > > Damian > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgalt at gmx.net Mon Oct 25 17:20:45 2021 From: hgalt at gmx.net (HGAlt) Date: Mon, 25 Oct 2021 19:20:45 +0200 Subject: [Icecast] Https Meta data Message-ID: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> I have a problem with https streaming. In VLC no meta data will be displayed. This seems to be an known problem! If you search in the internet, you will find a comment from VLC, that the problem is created by Icecast. Is there any possibility to solve this problem? Thanks, Hans-Georg -- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From epirat07 at gmail.com Mon Oct 25 17:23:54 2021 From: epirat07 at gmail.com (Marvin Scholz) Date: Mon, 25 Oct 2021 19:23:54 +0200 Subject: [Icecast] Https Meta data In-Reply-To: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> Message-ID: <2620DB4C-9190-4BD3-9D6B-1C538CE8D137@gmail.com> On 25 Oct 2021, at 19:20, HGAlt wrote: > I have a problem with https streaming. In VLC no meta data will be > displayed. > > This seems to be an known problem! If you search in the internet, you > will > find a comment from VLC, that the problem is created by Icecast. Where did you find this comment? This is not true. Lack of ICY metadata support for HTTPS streams in VLC is a known issue in all VLC 3.x versions, due to the way handling of such streams is implemented in VLC. It has nothing to do with Icecast and there is nothing that can be done on Icecasts side to fix this. > > > > Is there any possibility to solve this problem? > > > > Thanks, > > Hans-Georg > > > > > > -- > Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. > https://www.avast.com/antivirus > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From phschafft at de.loewenfelsen.net Mon Oct 25 17:33:36 2021 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 25 Oct 2021 17:33:36 +0000 Subject: [Icecast] Https Meta data In-Reply-To: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> Message-ID: Good evening, On Mon, 2021-10-25 at 19:20 +0200, HGAlt wrote: > I have a problem with https streaming. In VLC no meta data will be > displayed. > This seems to be an known problem! If you search in the internet, you > will find a comment from VLC, that the problem is created by Icecast. > > Is there any possibility to solve this problem? let me do a wild guess here: You are using MP3, or AAC. MP3, as well as AAC do not support metadata (unlike modern streaming formats) by themself. So they require the use of ICY as a transport. ICY is a workaround protocol by former Nullsoft that was meant only for letting Winamp talk with shoutcast. However Icecast has full emulation of that. TLS or not. To Icecast it is "all the same". And here is the big but: As Nullsoft decided that it is a "good" idea to use the "http" URI scheme for their protocol now players must check when the user enters a "http" URL if that is actually HTTP or ICY. So the player does magic here. And as this is dirty black magic nobody likes it. Therefore players have never implemented it for "https". As "https" always meant "https" not "icys". And for reasons of not confusing things even more that is very good. However there is also no correct scheme as there never was one registered. So there is no standard way of telling a player to use "icys". Meaning, metadata will only work if not used with a legacy codec. Some players accept URLs with "icys", "icyxs", or "xicys",... But that really depends on the player. Icecast itself (all versions!) are happy to send those metadata if a player asks for them. So on the Icecast side there is nothing to do. My suggestion is migration to e.g. Opus for streaming which is basically "THE" state of the art codec. With Opus metadata just works. I hope this was helpful, both for you and everyone else reading. With best regards, -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From yahav.shasha at gmail.com Mon Oct 25 17:43:11 2021 From: yahav.shasha at gmail.com (Yahav Shasha) Date: Mon, 25 Oct 2021 20:43:11 +0300 Subject: [Icecast] Https Meta data In-Reply-To: References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> Message-ID: If we're on the subject of Opus, is there any reliable way to playback opus http/s streams in iOS/MacOS Safari yet? ?????? ??? ??, 25 ????? 2021, 20:33, ??? Philipp Schafft ?< phschafft at de.loewenfelsen.net>: > Good evening, > > On Mon, 2021-10-25 at 19:20 +0200, HGAlt wrote: > > I have a problem with https streaming. In VLC no meta data will be > > displayed. > > This seems to be an known problem! If you search in the internet, you > > will find a comment from VLC, that the problem is created by Icecast. > > > > Is there any possibility to solve this problem? > > let me do a wild guess here: You are using MP3, or AAC. > > MP3, as well as AAC do not support metadata (unlike modern streaming > formats) by themself. So they require the use of ICY as a transport. > ICY is a workaround protocol by former Nullsoft that was meant only for > letting Winamp talk with shoutcast. However Icecast has full emulation > of that. TLS or not. To Icecast it is "all the same". > > And here is the big but: > > As Nullsoft decided that it is a "good" idea to use the "http" URI > scheme for their protocol now players must check when the user enters a > "http" URL if that is actually HTTP or ICY. So the player does magic > here. And as this is dirty black magic nobody likes it. Therefore > players have never implemented it for "https". As "https" always meant > "https" not "icys". And for reasons of not confusing things even more > that is very good. > > However there is also no correct scheme as there never was one > registered. So there is no standard way of telling a player to use > "icys". Meaning, metadata will only work if not used with a legacy > codec. > > Some players accept URLs with "icys", "icyxs", or "xicys",... But that > really depends on the player. > > Icecast itself (all versions!) are happy to send those metadata if a > player asks for them. So on the Icecast side there is nothing to do. > > My suggestion is migration to e.g. Opus for streaming which is > basically "THE" state of the art codec. With Opus metadata just works. > > I hope this was helpful, both for you and everyone else reading. > > With best regards, > > -- > Philipp Schafft (CEO/Gesch?ftsf?hrer) > Telephon: +49.3535 490 17 92 > > L?wenfelsen UG (haftungsbeschr?nkt) Registration number: > Bickinger Stra?e 21 HRB 12308 CB > 04916 Herzberg (Elster) VATIN/USt-ID: > Germany DE305133015 > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgalt at gmx.net Mon Oct 25 17:44:35 2021 From: hgalt at gmx.net (HGAlt) Date: Mon, 25 Oct 2021 19:44:35 +0200 Subject: [Icecast] Https Meta data In-Reply-To: <2620DB4C-9190-4BD3-9D6B-1C538CE8D137@gmail.com> References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> <2620DB4C-9190-4BD3-9D6B-1C538CE8D137@gmail.com> Message-ID: <003501d7c9c7$fa1a6e30$ee4f4a90$@gmx.net> Hi Martin, https://github.com/AzuraCast/AzuraCast/issues/1598 Pascalla commented on 3 Jun 2019 -----Urspr?ngliche Nachricht----- Von: Icecast [mailto:icecast-bounces at xiph.org] Im Auftrag von Marvin Scholz Gesendet: Montag, 25. Oktober 2021 19:24 An: Icecast streaming server user discussions Betreff: Re: [Icecast] Https Meta data On 25 Oct 2021, at 19:20, HGAlt wrote: > I have a problem with https streaming. In VLC no meta data will be > displayed. > > This seems to be an known problem! If you search in the internet, you > will > find a comment from VLC, that the problem is created by Icecast. Where did you find this comment? This is not true. Lack of ICY metadata support for HTTPS streams in VLC is a known issue in all VLC 3.x versions, due to the way handling of such streams is implemented in VLC. It has nothing to do with Icecast and there is nothing that can be done on Icecasts side to fix this. > > > > Is there any possibility to solve this problem? > > > > Thanks, > > Hans-Georg > > > > > > -- > Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. > https://www.avast.com/antivirus > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast _______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast -- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. https://www.avast.com/antivirus From phschafft at de.loewenfelsen.net Mon Oct 25 17:50:33 2021 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 25 Oct 2021 17:50:33 +0000 Subject: [Icecast] Can you play Opus streams on iOS? -> Yes, you can [WAS: Re: Https Meta data] In-Reply-To: References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> Message-ID: Good evening, On Mon, 2021-10-25 at 20:43 +0300, Yahav Shasha wrote: > If we're on the subject of Opus, is there any reliable way to > playback opus http/s streams in iOS/MacOS Safari yet? please don't hijack threads... To your question: Apple tries to be in the way here again. They try to be different to be different... However there are several libraries and player supporting this. Which is the one for your use case depends on your usecase. Plus there is no reason not to also provide a low quality MP3 stream for apple users. "Sadly the Vendor of your device did not add support for premium quality streams, so we are presenting you a low quality stream". Volla, your solution. With best regards, -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From hgalt at gmx.net Mon Oct 25 17:57:56 2021 From: hgalt at gmx.net (HGAlt) Date: Mon, 25 Oct 2021 19:57:56 +0200 Subject: [Icecast] Https Meta data In-Reply-To: References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> Message-ID: <003d01d7c9c9$d7b67f30$87237d90$@gmx.net> Hi Philipp, I am using MP3, but the meta data will provided by mairlist. Mairlist sends the stream to Icecast and it works fine http but not with https. My understanding is, that this information is not part of MP3, because mairlist only sends the audio data and not the MP3. The meta data will be send separate to Icecast. But with https VLC doesn't show them! Hi Marvin, Do you know any player that show the meta data foe https? Maybe VLC and Icecast should communicate directly the solve this problem. What do you think? -----Urspr?ngliche Nachricht----- Von: Icecast [mailto:icecast-bounces at xiph.org] Im Auftrag von Philipp Schafft Gesendet: Montag, 25. Oktober 2021 19:34 An: Icecast streaming server user discussions Betreff: Re: [Icecast] Https Meta data Good evening, On Mon, 2021-10-25 at 19:20 +0200, HGAlt wrote: > I have a problem with https streaming. In VLC no meta data will be > displayed. > This seems to be an known problem! If you search in the internet, you > will find a comment from VLC, that the problem is created by Icecast. > > Is there any possibility to solve this problem? let me do a wild guess here: You are using MP3, or AAC. MP3, as well as AAC do not support metadata (unlike modern streaming formats) by themself. So they require the use of ICY as a transport. ICY is a workaround protocol by former Nullsoft that was meant only for letting Winamp talk with shoutcast. However Icecast has full emulation of that. TLS or not. To Icecast it is "all the same". And here is the big but: As Nullsoft decided that it is a "good" idea to use the "http" URI scheme for their protocol now players must check when the user enters a "http" URL if that is actually HTTP or ICY. So the player does magic here. And as this is dirty black magic nobody likes it. Therefore players have never implemented it for "https". As "https" always meant "https" not "icys". And for reasons of not confusing things even more that is very good. However there is also no correct scheme as there never was one registered. So there is no standard way of telling a player to use "icys". Meaning, metadata will only work if not used with a legacy codec. Some players accept URLs with "icys", "icyxs", or "xicys",... But that really depends on the player. Icecast itself (all versions!) are happy to send those metadata if a player asks for them. So on the Icecast side there is nothing to do. My suggestion is migration to e.g. Opus for streaming which is basically "THE" state of the art codec. With Opus metadata just works. I hope this was helpful, both for you and everyone else reading. With best regards, -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. https://www.avast.com/antivirus From phschafft at de.loewenfelsen.net Mon Oct 25 18:07:57 2021 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 25 Oct 2021 18:07:57 +0000 Subject: [Icecast] Https Meta data In-Reply-To: <003d01d7c9c9$d7b67f30$87237d90$@gmx.net> References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> <003d01d7c9c9$d7b67f30$87237d90$@gmx.net> Message-ID: <8df9562c7c855c69e4d9a5d0b18eecbc40e65225.camel@de.loewenfelsen.net> Good evening, On Mon, 2021-10-25 at 19:57 +0200, HGAlt wrote: > Hi Philipp, > > I am using MP3, but the meta data will provided by mairlist. > Mairlist sends the stream to Icecast and it works fine http but not > with https. > > My understanding is, that this information is not part of MP3, > because mairlist only sends the audio data and not the MP3. The meta > data will be send separate to Icecast. But with https VLC doesn't > show them! Exactly this separation is the point. That separation is what ICY is about. MP3 does not support metadata so a side channel is needed as a workaround. Icecast does provide this just fine if asked for it. > Hi Marvin, > > Do you know any player that show the meta data foe https? > Maybe VLC and Icecast should communicate directly the solve this > problem. > What do you think? And again, there is nothing to do on the Icecast side. Let me make this clear: Icecast's listener protocol handling code does not even know if the client is connected via TLS or not. I don't want to point here at VLC. Also keeping in mind that others behave the same way. I just want to make clear that there is nothing we can do on the Icecast side as there is no problem on the Icecast side. With best regards, > -----Urspr?ngliche Nachricht----- > Von: Icecast [mailto:icecast-bounces at xiph.org] Im Auftrag von Philipp > Schafft > Gesendet: Montag, 25. Oktober 2021 19:34 > An: Icecast streaming server user discussions > Betreff: Re: [Icecast] Https Meta data > > Good evening, > > On Mon, 2021-10-25 at 19:20 +0200, HGAlt wrote: > > I have a problem with https streaming. In VLC no meta data will be > > displayed. > > This seems to be an known problem! If you search in the internet, > > you > > will find a comment from VLC, that the problem is created by > > Icecast. > > > > Is there any possibility to solve this problem? > > let me do a wild guess here: You are using MP3, or AAC. > > MP3, as well as AAC do not support metadata (unlike modern streaming > formats) by themself. So they require the use of ICY as a transport. > ICY is a workaround protocol by former Nullsoft that was meant only > for letting Winamp talk with shoutcast. However Icecast has full > emulation of that. TLS or not. To Icecast it is "all the same". > > And here is the big but: > > As Nullsoft decided that it is a "good" idea to use the "http" URI > scheme for their protocol now players must check when the user enters > a "http" URL if that is actually HTTP or ICY. So the player does > magic here. And as this is dirty black magic nobody likes it. > Therefore players have never implemented it for "https". As "https" > always meant "https" not "icys". And for reasons of not confusing > things even more that is very good. > > However there is also no correct scheme as there never was one > registered. So there is no standard way of telling a player to use > "icys". Meaning, metadata will only work if not used with a legacy > codec. > > Some players accept URLs with "icys", "icyxs", or "xicys",... But > that really depends on the player. > > Icecast itself (all versions!) are happy to send those metadata if a > player asks for them. So on the Icecast side there is nothing to do. > > My suggestion is migration to e.g. Opus for streaming which is > basically "THE" state of the art codec. With Opus metadata just > works. > > I hope this was helpful, both for you and everyone else reading. > -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From dynamiteezeh at gmail.com Mon Oct 25 18:44:29 2021 From: dynamiteezeh at gmail.com (Isaac Ezeh) Date: Mon, 25 Oct 2021 19:44:29 +0100 Subject: [Icecast] Use endpoint to activate fallback-override Message-ID: Hi, I would like to activate fallback-override via an endpoint For example, according to the documentation To set up the fallback mountpoint of a mount I use this endpoint /admin/fallbacks?mount=/stream.ogg&fallback=/fallback.ogg Is it possible to also have an endpoint to set up the fallback override? Like this; /admin/fallbacks?mount=/stream.ogg&fallback-override=1 -- Regards, Isaac Ezeh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgalt at gmx.net Tue Oct 26 08:27:28 2021 From: hgalt at gmx.net (HGAlt) Date: Tue, 26 Oct 2021 10:27:28 +0200 Subject: [Icecast] Https Meta data In-Reply-To: <8df9562c7c855c69e4d9a5d0b18eecbc40e65225.camel@de.loewenfelsen.net> References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> <003d01d7c9c9$d7b67f30$87237d90$@gmx.net> <8df9562c7c855c69e4d9a5d0b18eecbc40e65225.camel@de.loewenfelsen.net> Message-ID: <002a01d7ca43$518354e0$f489fea0$@gmx.net> Hi Philipp, where can I find information, who to handle it? -----Urspr?ngliche Nachricht----- Von: Icecast [mailto:icecast-bounces at xiph.org] Im Auftrag von Philipp Schafft Gesendet: Montag, 25. Oktober 2021 20:08 An: Icecast streaming server user discussions Betreff: Re: [Icecast] Https Meta data Good evening, On Mon, 2021-10-25 at 19:57 +0200, HGAlt wrote: > Hi Philipp, > > I am using MP3, but the meta data will provided by mairlist. > Mairlist sends the stream to Icecast and it works fine http but not > with https. > > My understanding is, that this information is not part of MP3, because > mairlist only sends the audio data and not the MP3. The meta data will > be send separate to Icecast. But with https VLC doesn't show them! Exactly this separation is the point. That separation is what ICY is about. MP3 does not support metadata so a side channel is needed as a workaround. Icecast does provide this just fine if asked for it. > Hi Marvin, > > Do you know any player that show the meta data foe https? > Maybe VLC and Icecast should communicate directly the solve this > problem. > What do you think? And again, there is nothing to do on the Icecast side. Let me make this clear: Icecast's listener protocol handling code does not even know if the client is connected via TLS or not. I don't want to point here at VLC. Also keeping in mind that others behave the same way. I just want to make clear that there is nothing we can do on the Icecast side as there is no problem on the Icecast side. With best regards, > -----Urspr?ngliche Nachricht----- > Von: Icecast [mailto:icecast-bounces at xiph.org] Im Auftrag von Philipp > Schafft > Gesendet: Montag, 25. Oktober 2021 19:34 > An: Icecast streaming server user discussions > Betreff: Re: [Icecast] Https Meta data > > Good evening, > > On Mon, 2021-10-25 at 19:20 +0200, HGAlt wrote: > > I have a problem with https streaming. In VLC no meta data will be > > displayed. > > This seems to be an known problem! If you search in the internet, > > you will find a comment from VLC, that the problem is created by > > Icecast. > > > > Is there any possibility to solve this problem? > > let me do a wild guess here: You are using MP3, or AAC. > > MP3, as well as AAC do not support metadata (unlike modern streaming > formats) by themself. So they require the use of ICY as a transport. > ICY is a workaround protocol by former Nullsoft that was meant only > for letting Winamp talk with shoutcast. However Icecast has full > emulation of that. TLS or not. To Icecast it is "all the same". > > And here is the big but: > > As Nullsoft decided that it is a "good" idea to use the "http" URI > scheme for their protocol now players must check when the user enters > a "http" URL if that is actually HTTP or ICY. So the player does magic > here. And as this is dirty black magic nobody likes it. > Therefore players have never implemented it for "https". As "https" > always meant "https" not "icys". And for reasons of not confusing > things even more that is very good. > > However there is also no correct scheme as there never was one > registered. So there is no standard way of telling a player to use > "icys". Meaning, metadata will only work if not used with a legacy > codec. > > Some players accept URLs with "icys", "icyxs", or "xicys",... But that > really depends on the player. > > Icecast itself (all versions!) are happy to send those metadata if a > player asks for them. So on the Icecast side there is nothing to do. > > My suggestion is migration to e.g. Opus for streaming which is > basically "THE" state of the art codec. With Opus metadata just works. > > I hope this was helpful, both for you and everyone else reading. > -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. https://www.avast.com/antivirus From phschafft at de.loewenfelsen.net Tue Oct 26 09:15:44 2021 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Tue, 26 Oct 2021 09:15:44 +0000 Subject: [Icecast] Https Meta data In-Reply-To: <002a01d7ca43$518354e0$f489fea0$@gmx.net> References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> <003d01d7c9c9$d7b67f30$87237d90$@gmx.net> <8df9562c7c855c69e4d9a5d0b18eecbc40e65225.camel@de.loewenfelsen.net> <002a01d7ca43$518354e0$f489fea0$@gmx.net> Message-ID: <8162d239352b4810fde8bd7f7f6e699906983b79.camel@de.loewenfelsen.net> Good morning, On Tue, 2021-10-26 at 10:27 +0200, HGAlt wrote: > Hi Philipp, > > where can I find information, who to handle it? I'm sorry, but I fear I do not understand your question. With best regards, > -----Urspr?ngliche Nachricht----- > Von: Icecast [mailto:icecast-bounces at xiph.org] Im Auftrag von Philipp > Schafft > Gesendet: Montag, 25. Oktober 2021 20:08 > An: Icecast streaming server user discussions > Betreff: Re: [Icecast] Https Meta data > > Good evening, > > On Mon, 2021-10-25 at 19:57 +0200, HGAlt wrote: > > Hi Philipp, > > > > I am using MP3, but the meta data will provided by mairlist. > > Mairlist sends the stream to Icecast and it works fine http but not > > with https. > > > > My understanding is, that this information is not part of MP3, > > because > > mairlist only sends the audio data and not the MP3. The meta data > > will > > be send separate to Icecast. But with https VLC doesn't show them! > > Exactly this separation is the point. That separation is what ICY is > about. MP3 does not support metadata so a side channel is needed as a > workaround. > > Icecast does provide this just fine if asked for it. > > > > Hi Marvin, > > > > Do you know any player that show the meta data foe https? > > Maybe VLC and Icecast should communicate directly the solve this > > problem. > > What do you think? > > And again, there is nothing to do on the Icecast side. Let me make > this > clear: Icecast's listener protocol handling code does not even know > if the client is connected via TLS or not. > > I don't want to point here at VLC. Also keeping in mind that others > behave the same way. I just want to make clear that there is nothing > we can do on the Icecast side as there is no problem on the Icecast > side. > -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From phschafft at de.loewenfelsen.net Tue Oct 26 10:12:53 2021 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Tue, 26 Oct 2021 10:12:53 +0000 Subject: [Icecast] Use endpoint to activate fallback-override In-Reply-To: References: Message-ID: <1c66c9eb25eb2ae185f745ceea3e70ee87c3e78c.camel@de.loewenfelsen.net> Good morning, On Mon, 2021-10-25 at 19:44 +0100, Isaac Ezeh wrote: > Hi, > > I would like to activate fallback-override via an endpoint > > For example, according to the documentation > To set up the fallback mountpoint of a mount I use this endpoint > /admin/fallbacks?mount=/stream.ogg&fallback=/fallback.ogg > > Is it possible to also have an endpoint to set up the fallback > override? > Like this; > /admin/fallbacks?mount=/stream.ogg&fallback-override=1 thank you for your interest. At this point it is not possible. But: Generally I'm not sure if this kind of on-the-fly reconfiguration that is not backed by config change is the direction we want to go. If there is a specific usecase I'm surely interested in hearing about it as... this gives valuable input to exactly this decision. I would love to see a ticket about this. Do you want to open one?: https://gitlab.xiph.org/xiph/icecast-server Otherwise I would open one but I think if you open it you can include a bit more background story directly. With best regards, -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From dynamiteezeh at gmail.com Wed Oct 27 04:51:45 2021 From: dynamiteezeh at gmail.com (Isaac Ezeh) Date: Wed, 27 Oct 2021 05:51:45 +0100 Subject: [Icecast] Use endpoint to activate fallback-override In-Reply-To: <1c66c9eb25eb2ae185f745ceea3e70ee87c3e78c.camel@de.loewenfelsen.net> References: <1c66c9eb25eb2ae185f745ceea3e70ee87c3e78c.camel@de.loewenfelsen.net> Message-ID: Hi Philip, Thank you so much for your swift response. I am creating the issue on GitLab as we speak. I also have another very pertinent issue. I want to serve my icecast server over https, but I am unfortunately finding it super difficult. I have tried to scrape the internet for solutions, all to no avail. I was able to set up https at a point but the challenge I then face is that when I start streaming into a mountpoint, it automatically stops after 40secs for all streams. I also want to note that I am using LetsEncrypt for my https and also using NGINX for the reverse proxy so that I can setup a custom domain rather than a bare IP-Address Kindly find below the configuration of my NGINX server block server { listen 80; server_name stream.mydomain.com www.stream.mydomain.com; location / { proxy_pass http://localhost:8000; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.0-fpm.sock; } location ~ /\.ht { deny all; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/ www.stream.mydomain.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/ www.stream.mydomain.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } P.S I did not make any change to my icecast.xml file with respect to ssl, just the default configuration it takes to set up an icecast server. This configuration works pretty well when I disable *NGINX* and *ufw*, but the issue described above crops up when I want to serve icecast over https (i.e enable NGINX and ufw). On Tue, Oct 26, 2021 at 11:13 AM Philipp Schafft < phschafft at de.loewenfelsen.net> wrote: > Good morning, > > On Mon, 2021-10-25 at 19:44 +0100, Isaac Ezeh wrote: > > Hi, > > > > I would like to activate fallback-override via an endpoint > > > > For example, according to the documentation > > To set up the fallback mountpoint of a mount I use this endpoint > > /admin/fallbacks?mount=/stream.ogg&fallback=/fallback.ogg > > > > Is it possible to also have an endpoint to set up the fallback > > override? > > Like this; > > /admin/fallbacks?mount=/stream.ogg&fallback-override=1 > > thank you for your interest. > > At this point it is not possible. But: > > Generally I'm not sure if this kind of on-the-fly reconfiguration that > is not backed by config change is the direction we want to go. If there > is a specific usecase I'm surely interested in hearing about it as... > this gives valuable input to exactly this decision. > > I would love to see a ticket about this. Do you want to open one?: > https://gitlab.xiph.org/xiph/icecast-server > > Otherwise I would open one but I think if you open it you can include a > bit more background story directly. > > > With best regards, > > -- > Philipp Schafft (CEO/Gesch?ftsf?hrer) > Telephon: +49.3535 490 17 92 > > L?wenfelsen UG (haftungsbeschr?nkt) Registration number: > Bickinger Stra?e 21 HRB 12308 CB > 04916 Herzberg (Elster) VATIN/USt-ID: > Germany DE305133015 > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -- Regards, Isaac Ezeh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvandop at xs4all.nl Sat Oct 30 08:56:30 2021 From: mvandop at xs4all.nl (Michel van Dop) Date: Sat, 30 Oct 2021 10:56:30 +0200 (CEST) Subject: [Icecast] Https Meta data In-Reply-To: References: <001601d7c9c4$a5b22ed0$f1168c70$@gmx.net> Message-ID: <321888810.122474.1635584190786@ox-webmail.xs4all.nl> Hi, I see: > My suggestion is migration to e.g. Opus for streaming which is > basically "THE" state of the art codec. With Opus metadata just works. The Opus encoder is very good. Only works on 48Khz, not on 44.1Khz, but the meta data update do not work. We use the ProppFrexx onair play-out (44.1Khz) and his encoders. Check http://www.proppfrexx.radio42.com/forum/viewtopic.php?t=2003 How to fix this? We try other Rocket broadcaster server and the meta works fine for flac and opus. Best regards, Michel > Op 25-10-2021 19:33 schreef Philipp Schafft : > > > Good evening, > > On Mon, 2021-10-25 at 19:20 +0200, HGAlt wrote: > > I have a problem with https streaming. In VLC no meta data will be > > displayed. > > This seems to be an known problem! If you search in the internet, you > > will find a comment from VLC, that the problem is created by Icecast. > > > > Is there any possibility to solve this problem? > > let me do a wild guess here: You are using MP3, or AAC. > > MP3, as well as AAC do not support metadata (unlike modern streaming > formats) by themself. So they require the use of ICY as a transport. > ICY is a workaround protocol by former Nullsoft that was meant only for > letting Winamp talk with shoutcast. However Icecast has full emulation > of that. TLS or not. To Icecast it is "all the same". > > And here is the big but: > > As Nullsoft decided that it is a "good" idea to use the "http" URI > scheme for their protocol now players must check when the user enters a > "http" URL if that is actually HTTP or ICY. So the player does magic > here. And as this is dirty black magic nobody likes it. Therefore > players have never implemented it for "https". As "https" always meant > "https" not "icys". And for reasons of not confusing things even more > that is very good. > > However there is also no correct scheme as there never was one > registered. So there is no standard way of telling a player to use > "icys". Meaning, metadata will only work if not used with a legacy > codec. > > Some players accept URLs with "icys", "icyxs", or "xicys",... But that > really depends on the player. > > Icecast itself (all versions!) are happy to send those metadata if a > player asks for them. So on the Icecast side there is nothing to do. > > My suggestion is migration to e.g. Opus for streaming which is > basically "THE" state of the art codec. With Opus metadata just works. > > I hope this was helpful, both for you and everyone else reading. > > With best regards, > > -- > Philipp Schafft (CEO/Gesch?ftsf?hrer) > Telephon: +49.3535 490 17 92 > > L?wenfelsen UG (haftungsbeschr?nkt) Registration number: > Bickinger Stra?e 21 HRB 12308 CB > 04916 Herzberg (Elster) VATIN/USt-ID: > Germany DE305133015 > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From railgun.michael at gmail.com Sun Oct 31 16:06:56 2021 From: railgun.michael at gmail.com (Railgun) Date: Sun, 31 Oct 2021 17:06:56 +0100 Subject: [Icecast] option Message-ID: <39d6cc0d-ea6b-f2f6-e893-319a3e6cae0b@gmail.com> hi i'm using icecast as version 2.4.99.2 i know that there was a no-moint option to fallback that users cant conect directly to it somone can tell me the option for my config file From phschafft at de.loewenfelsen.net Sun Oct 31 18:14:29 2021 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Sun, 31 Oct 2021 18:14:29 +0000 Subject: [Icecast] option In-Reply-To: <39d6cc0d-ea6b-f2f6-e893-319a3e6cae0b@gmail.com> References: <39d6cc0d-ea6b-f2f6-e893-319a3e6cae0b@gmail.com> Message-ID: <29f8f7f429db9a40a4899a22cca6abf22e8c6991.camel@de.loewenfelsen.net> Good afternoon, On Sun, 2021-10-31 at 17:06 +0100, Railgun wrote: > hi > > i'm using icecast as version 2.4.99.2 > > i know that there was a no-moint option to fallback that users cant > conect directly to it somone can tell me the option for my config > file thank you for your E-Mail. When it reached me we actually discussed the future of the option in a meeting. :) It is true within the corresponding -tag. Please note that you need to have a "recent" build as some older revisions from the 2.5.x branch had a regression leading to the tag being ignored. With best regards, -- Philipp Schafft (CEO/Gesch?ftsf?hrer) Telephon: +49.3535 490 17 92 L?wenfelsen UG (haftungsbeschr?nkt) Registration number: Bickinger Stra?e 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From ThomasPrivat92 at gmx.de Sun Oct 31 20:31:50 2021 From: ThomasPrivat92 at gmx.de (Thomas) Date: Sun, 31 Oct 2021 21:31:50 +0100 Subject: [Icecast] option In-Reply-To: <29f8f7f429db9a40a4899a22cca6abf22e8c6991.camel@de.loewenfelsen.net> References: <39d6cc0d-ea6b-f2f6-e893-319a3e6cae0b@gmail.com> <29f8f7f429db9a40a4899a22cca6abf22e8c6991.camel@de.loewenfelsen.net> Message-ID: <777c2ec0-5504-5731-6be3-4711ccad2f03@gmx.de> thank you i realy like that option because somtimes its good to have the data of the "mount" on puplic and not hidden, but no one should conect directly to it. i use this option as fallback mount of the main stream Am 31.10.2021 um 19:14 schrieb Philipp Schafft: > Good afternoon, > > On Sun, 2021-10-31 at 17:06 +0100, Railgun wrote: >> hi >> >> i'm using icecast as version 2.4.99.2 >> >> i know that there was a no-moint option to fallback that users cant >> conect directly to it somone can tell me the option for my config >> file > thank you for your E-Mail. When it reached me we actually discussed the > future of the option in a meeting. :) > > It is true within the corresponding -tag. > > Please note that you need to have a "recent" build as some older > revisions from the 2.5.x branch had a regression leading to the tag > being ignored. > > > With best regards, > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: