At 05:31 PM 6/25/2003 +1000, you wrote:> > I'm not concerned with how players see anything right now, tho that is a > > concern I guess. I'm concerned with getting the vitals - the stream > > name, genre, and description, to be relayed to a YP server when Icecast2 > > is relaying a Shoutcast stream. Currently it does not, this is missing > > functionality that needs to be provided because currently it's "breaking > > protocol" (as defined by Oddsock's Icecast2 YP document) by sending add > > requests without a stream name. go back a few emails, see where this > > came from.. one of three bugs in Icecast's YP support. A fairly minor > > one compaired to the memory leak bug, but still very problematic for us. > >Ok. I guess I don't see these as 'vitals' - which is why we were talking >about >different things. > >Probably a bug in the stats header parser or the YP code. Shouldn't be >hard to >fix (I can't - don't have cvs access from work, don't have internet access >from home, currently - but there are several developers who know how the >stats stuff works) > >Mikethe problem is with the parsing of the source, it is looking for ice-* and not the icy-* in the source header. The question is, do we want to support the icy headers from shoutcast ? I suppose we probably should, but it's a bit irritating having to put shoutcast compatibility code in icecast..... oddsock <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, Jun 25, 2003 at 08:31:32AM -0500, oddsock wrote:> > the problem is with the parsing of the source, it is looking for ice-* and > not the icy-* in the source header. The question is, do we want to support > the icy headers from shoutcast ? I suppose we probably should, but it's a > bit irritating having to put shoutcast compatibility code in icecast.....But remember, the lack of such supports means (for instance) that we, in order to relay a shoutcast stream properly, would have to relay it with shoutcast. Not to mention, that if i cant get relay'ed shoutcast streams on the YP server soon I'm going to have to code in Shoutcast support to my YP server in addition to setting up a Shoutcast relay server, a double plus bad thing. <p> -------------- next part -------------- A non-text attachment was scrubbed... Name: part Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20030625/43a6ef0e/part.pgp
> >Probably a bug in the stats header parser or the YP code. Shouldn't be > >hard to > >fix (I can't - don't have cvs access from work, don't have internet access > >from home, currently - but there are several developers who know how the > >stats stuff works) > > > >Mike > > the problem is with the parsing of the source, it is looking for ice-* and > not the icy-* in the source header. The question is, do we want to support > the icy headers from shoutcast ? I suppose we probably should, but it's a > bit irritating having to put shoutcast compatibility code in icecast.....Why, yes it is. There's already quite a lot of shoutcast compatibility code in there... though not all of it works (the shoutcastDSP-protocol-compatibility code is utterly broken, for instance). I don't think it's a big deal to check for icy-* as well as ice-*, personally, but I'm not going to be doing it. Mike <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, Jun 25, 2003 at 08:31:32AM -0500, oddsock wrote:> the problem is with the parsing of the source, it is looking for ice-* and > not the icy-* in the source header. The question is, do we want to support > the icy headers from shoutcast ? I suppose we probably should, but it's a > bit irritating having to put shoutcast compatibility code in icecast.....Let's not loose sight of the other two bugs, which I personally think are more serious... 1) The memory leak issue caused when Icecast has streams rejected from a YP server, reproduce either with a broken YP CGI or with a non-existant YP server.. with many streams getting rejected causes a Icecast server to consume over 100megs in less than an hour 2) Icecast continually (every 15 seconds or so, apparently) trying to re-publish rejected streams vs "holding off" for a reasonable amount of time before retrying. This is this causing the memory leak issue to grow much larger than it would otherwise, it could potentially cause an already overloaded YP server to get even more overloaded when it cant handle requests timely enough vs holding off until the server has had time to "cool off". The shoutcast metainfo problem may be easy to fix, and would be extremely useful, but especially #1 is a critical bug and needs to be fixed. Oddsock, you should still have access to the server here if you need to be here in order to do memory debugging/etc.. that is if you want to tackle this problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: part Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20030626/e8fc1a51/part.pgp
At 02:16 AM 6/26/2003 -0400, you wrote:>On Wed, Jun 25, 2003 at 08:31:32AM -0500, oddsock wrote: > > the problem is with the parsing of the source, it is looking for ice-* and > > not the icy-* in the source header. The question is, do we want to > support > > the icy headers from shoutcast ? I suppose we probably should, but it's a > > bit irritating having to put shoutcast compatibility code in icecast..... > >Let's not loose sight of the other two bugs, which I personally think >are more serious... > >1) The memory leak issue caused when Icecast has streams rejected from >a YP server, reproduce either with a broken YP CGI or with a >non-existant YP server.. with many streams getting rejected causes a >Icecast server to consume over 100megs in less than an hourI was hoping to get a valgrind report from you regarding what this memory leak was...as I mentioned before, I did find a memory leak or two in parts of the YP-related code...If you are experiencing a reproducable memory leak, valgrind is the way to identify it...Providing a valgrind report is a sure fire way to get a memory leak fixed, without that, we have to try to reproduce it ourselves, which can be quite difficult sometimes and take up alot of time...anyway, I just committed the memory leak fix, so please let us know if you are still seeing leaks.>2) Icecast continually (every 15 seconds or so, apparently) trying to >re-publish rejected streams vs "holding off" for a reasonable amount of >time before retrying. This is this causing the memory leak issue to >grow much larger than it would otherwise, it could potentially cause an >already overloaded YP server to get even more overloaded when it cant >handle requests timely enough vs holding off until the server has had >time to "cool off".well, the logic in this respect is fairly simple and doesn't have any knowledge of multiple types of failures....If you set it too high (the retry interval) then you get complaints regarding it taking too long for the stream to list when a problem arises (network or yp-server related)....The current minimum touch interval is 30 seconds. Also note that each stream/yp pair has it's own touch interval which is set by the yp server on an successful yp-add. In the case of a yp-add failure, the touch interval is set to 30 seconds, which means that every 30 seconds, icecast will try to re-list that stream on that yp. Although, I'm not sure making this configurable really is what we want, since if you are running into trouble yp-adding and it's a YP server unavailablility problem, then you'd want the server to continue to retry at a relatively fast interval...If you are running into trouble yp-adding due to something that you are not providing on your source client (not providing server name for instance), then you should really fix this or turn off yp listing altogether. <p>oddsock <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.