On Mon, 2003-12-01 at 08:28, Melanie wrote:> > diff -b -B -r -u -P --exclude-from=ignore ../icecast/src/source.c > ./src/source.c > --- ../icecast/src/source.c Fri Nov 14 17:51:59 2003 > +++ ./src/source.c Mon Dec 1 09:14:34 2003 > @@ -139,7 +192,6 @@ > #endif > > free(source->mount); > - free(source->fallback_mount); > client_destroy(source->client); > avl_tree_free(source->pending_tree, _free_client); > avl_tree_free(source->client_tree, _free_client); > > > This is the patch and without it, anything using fallbacks will fail > miserably. It is the prerequisite for almost all other patches, because > this bug is a showstopper. Unless and until this patch is applied, all the > others are useless.Just to let you know, this isn't the actual fix. a simple config re-read can invalidate the pointer. karl. <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.
Hello, this is the first patch, it implements some basic multilevel fallback handling logic, the time window and the no mount option. New options are possible within an <mount> section: <fallback-override>1</fallback-override> This will allow a source connecting to a mount point to steal the clients from it's fallback mount. All clients of the fallback are transferred to the pending queue of the newly connected source. If the main source drops out, it's clients will, by means of <fallback-mount>, be connected to the fallback source. With this turned on, when the main source comes back online, the clients will be shifted back on reconnect. Without it, the clients will keep listening to the fallback. <no-mount>1</no-mount> This will refuse listener connection to the mount point in which it appears. Sources may still connect. The mount can be used as a fallback, this is the only way listeners can be connected to it when this option is set. Even if the mount name is known, direct connections are not possible. The reason for this is something that happened to us: our stream was hijacked and the mount point name was spread by IRC so people connected to it to listen to the pirate broadcast. Fortunately, no racist content was broadcast this time, but I made the addition to prevent that from happening. As a licensed station, we are responsible for our content and _must_ prevent racist content from airing. If we cannot do this, we will be shut down. <time-window>17:00-05:00</time-window> This option will restrict _sources_ from connecting to this stream outside the time window. We are required by law and contract to broadcast no more than 12 hours per day. Actually, we may broadcast all day, but only 12 hours worth of RIAA/GEMA/GVL music. I chose to limit source connection rather than listener connections because there may be a fallback carrying announcements or royalty-free music or such. This way, clients trying to connect to this mountpoint outside of the time window may still listen to this other source. Fallback and reconnect are handled in a multi-level fashion, where each fallback may in turn have a fallback. Specifying a circle of fallbacks is also possible, however, recovery will not go around the circle more than once. There is really no point in doing that, but XML permits it and the alternative to making it acceptable would have been to generate a config parse error. I didn't really want to add such a showstopper. Recovery only scans downward to the first connected source, that is all that's needed. By definition, no clients can be connected to lower level sources, unless they connected directly, in which case it's ok not to pick them up. The patch depends on the bugfix I sent earlier, the second version with strdup(). Melanie -------------- next part -------------- A non-text attachment was scrubbed... Name: icecast-combined.patch Type: text/x-patch Size: 13252 bytes Desc: icecast-combined.patch Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20031201/bc48664b/icecast-combined.bin
Here I go again. This is the second patch, it adds the ability to override some YP settings on the server. <yp-override>1</yp-override> If this is not set, we don't override the yp flag. <yp-public>1</yp-public> When this is set, the stream will be public or non public, according to it's content. This only works when yp-override is set. It allows to suppress yp reporting or to force it, or leave it under control of the source. <yp-name>MyRadio</yp-name> This will overwrite the name given by the source with the name specified here. <yp-url><a href="http://www.radio.com/myradio.html</yp-url">http://www.radio.com/myradio.html</yp-url</a>> This will force a specific URL to be listed with the YP server. Omit to let the source control this. <yp-genre>Mixed</yp-genre> This will force a genre, as with all yp-* options, omit for the old behavior. <yp-desc>My Super Duper radio station</yp-desc> Override and force the station comment. <yp-report-as>/myradio.ogg</yp-report-as> This will override the URL given to the YP server for stream listening. Now, before there is an outcry again, let me explain this one: Assume you have a mountpoint. This mountpoint has a fallback. Now, your main mountpoint's source disconnects. It's YP information is removed. So, you're no longer listed. Now, if the fallback is public, it would either always appear side by side with your main stream, but, even worse, if it's a no-mount, it would be useless. Nobody could listen to it, ever. report-as solves this: If a fallback is set to report as the name of it's top-level stream, it will not register with YP unless it becomes active, becomes the highest level active stream in it's chain. This will ensure that, even when there is a break in transmission or you're just playing your station jingle, your station will remain listed in YP, by the correct (primary) mount name. <mount> <mount-name>/station.ogg</mount-name> <yp-override>1</yp-override> <yp-public>1</yp-public> <fallback-mount>/fallback.ogg</fallback> </mount> <mount> <mount-name>/fallback.ogg</mount-name> <no-mount>1</no-mount> <yp-override>1</yp-override> <yp-public>1</yp-public> <yp-report-as>/station.ogg</yp-report-as> </mount> This will keep your stream online, connectable and listed correctly whenever at least one of the streams has a source, building on the concept that a stream and it's fallback(s) are logically one station and should be seen as a single URL from the outside world. Melanie --- >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.
> IMHO, a system like Icecast should be made so highly configurable that it > would fit everyone's needs, but I get the impression that only the needs of > the principal developers are of interest here. It makes me sad to see this, > Icecast could be great instead of just being good. >Melanie, As one of the 'principal developers', I don't think this is fair. Of the things you suggested, I said I was interested in seeing patches for all but one of them - and that one is better implemented elsewhere, as I said previously. Please, send us patches. Your complex-fallbacks one is of most interest, and we'd definately love to see that separately from the others, but the we'd also like to see separate patches for the other features, so that we can review them on their own merits (and commit them if we think they're good enough :-) Mike --- >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.
Hi, On 2003.12.01 02:57 Michael Smith wrote:> Please, send us patches. Your complex-fallbacks one is of most interest, > and > we'd definately love to see that separately from the others, but the we'd > also like to see separate patches for the other features, so that we can > review them on their own merits (and commit them if we think they're good > enough :-)I just checked out a fresh copy of Icecast CVS and I'm getting pretty discouraged when I see that not even the bugfix for the double free bug is in there yet. diff -b -B -r -u -P --exclude-from=ignore ../icecast/src/source.c ./src/source.c --- ../icecast/src/source.c Fri Nov 14 17:51:59 2003 +++ ./src/source.c Mon Dec 1 09:14:34 2003 @@ -139,7 +192,6 @@ #endif free(source->mount); - free(source->fallback_mount); client_destroy(source->client); avl_tree_free(source->pending_tree, _free_client); avl_tree_free(source->client_tree, _free_client); <p>This is the patch and without it, anything using fallbacks will fail miserably. It is the prerequisite for almost all other patches, because this bug is a showstopper. Unless and until this patch is applied, all the others are useless. Melanie --- >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 Mon, 2003-12-01 at 08:28, Melanie wrote:> I just checked out a fresh copy of Icecast CVS and I'm getting pretty > discouraged when I see that not even the bugfix for the double free bug is > in there yet. > > diff -b -B -r -u -P --exclude-from=ignore ../icecast/src/source.c > ./src/source.c > --- ../icecast/src/source.c Fri Nov 14 17:51:59 2003 > +++ ./src/source.c Mon Dec 1 09:14:34 2003 > @@ -139,7 +192,6 @@ > #endif > > free(source->mount); > - free(source->fallback_mount); > client_destroy(source->client); > avl_tree_free(source->pending_tree, _free_client); > avl_tree_free(source->client_tree, _free_client);hmm, I thought I fixed that one, will commit... karl. <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.
> I just checked out a fresh copy of Icecast CVS and I'm getting pretty > discouraged when I see that not even the bugfix for the double free bug is > in there yet. > > diff -b -B -r -u -P --exclude-from=ignore ../icecast/src/source.c > ./src/source.c > --- ../icecast/src/source.c Fri Nov 14 17:51:59 2003 > +++ ./src/source.c Mon Dec 1 09:14:34 2003 > @@ -139,7 +192,6 @@ > #endif > > free(source->mount); > - free(source->fallback_mount); > client_destroy(source->client); > avl_tree_free(source->pending_tree, _free_client); > avl_tree_free(source->client_tree, _free_client); > > > This is the patch and without it, anything using fallbacks will fail > miserably. It is the prerequisite for almost all other patches, because > this bug is a showstopper. Unless and until this patch is applied, all the > others are useless. >Melanie, Sorry about this one, I forgot about it. Your patch is incorrect, and will cause memory leaks - this has to be freed here. The bug is in how it is allocated to begin with. We can't just remove this, because (as well as the source.c initialisation) it can be free(), and replaced by a newly allocated string, in admin.c. So, this patch should work: diff -u -r1.59 source.c --- source.c 24 Jul 2003 16:21:22 -0000 1.59 +++ source.c 2 Dec 2003 00:36:56 -0000 @@ -72,7 +72,8 @@ src->yp_public = 0; if(mountinfo != NULL) { - src->fallback_mount = mountinfo->fallback_mount; + if(mountinfo->fallback_mount) + src->fallback_mount = strdup(mountinfo->fallback_mount); src->max_listeners = mountinfo->max_listeners; src->dumpfilename = mountinfo->dumpfile; } <p>Ok? Mike --- >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 Tuesday 02 December 2003 01:23, Melanie wrote:> Hello, > > this is the first patch, it implements some basic multilevel fallback > handling logic, the time window and the no mount option. > > New options are possible within an <mount> section: > > <fallback-override>1</fallback-override> > > This will allow a source connecting to a mount point to steal the clients > from it's fallback mount. All clients of the fallback are transferred to > the pending queue of the newly connected source. > If the main source drops out, it's clients will, by means of > <fallback-mount>, be connected to the fallback source. With this turned on, > when the main source comes back online, the clients will be shifted back on > reconnect. Without it, the clients will keep listening to the fallback. > > <no-mount>1</no-mount>These two are the major ones - I think this is a great new feature. However, we're trying to stabilise for 2.0 in the very near future, so I think this is probably more suitable for 2.1 (Note: we're hoping that 2.1 won't be long after 2.0, so this shouldn't delay it TOO long). Obviously, this sort of thing changes the core server logic quite a bit. <p>>> <time-window>17:00-05:00</time-window>I'd like to see this bit split out from the rest - it's unrelated. That doesn't mean it won't be accepted, but we'd MUCH rather see patches for one feature at a time. Could you manage that? As with the other stuff, documentation is neccesary as well. <p>> Fallback and reconnect are handled in a multi-level fashion, where each> fallback may in turn have a fallback. Specifying a circle of fallbacks is > also possible, however, recovery will not go around the circle more than > once. There is really no point in doing that, but XML permits it and the > alternative to making it acceptable would have been to generate a config > parse error. I didn't really want to add such a showstopper. > > Recovery only scans downward to the first connected source, that is all > that's needed. By definition, no clients can be connected to lower level > sources, unless they connected directly, in which case it's ok not to pick > them up.This all seems sensible. We need to detect this sort of error at runtime anyway (not only when reading the config file), since the config can be modified through the admin interface at any time, so this way of handling it sounds good. Mike --- >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.