Well, I've got it installed, and configured with several fallback-to-file mounts. I don't actually have any source clients connecting to it, but even so, the fallback-to-file mounts seem to work great. I'm very excited about this functionality since I've been running ezstream in the past which has given me all sorts of problems, most of which I've mentioned on this list. The fallback-to-file does just what I wanted ezstream to do without having to run a separate source client. Very nice! I have some questions related to fallback-to-file though. The fallback-to-file mounts seem to show up on the server status page. Is there a way to hide them? I don't really want people connecting to them directly, or really even knowing they are there. With ezstream I just created a <mount> section and made it hidden. Maybe I should try that. it might still work. This doesn't really affect me, but I'm curious about the behavior. If you have an ogg or mp3 in the webroot, you used to be able to just download it and play it. Now, it seems that if that file is configured as a fallback then you can't just download it anymore. If you specify the path to that file, you just get it streamed to you. Is there no way to just download that file anymore if it's configured as a fallback? This is probably a design consideration, but I'd like to understand the reasoning. I'd sort of expected for you to be able to download the file if you accessed it directly, but have it streamed if you were to fallback to it. I'm sure there's a reason, but I'd be interested in knowing it. Thanks, Joel oddsock wrote:> Just wanted to let everyone know that we also welcome reports such as > "everything works as expected" too. It's hard for us to gauge the > quality of the release unless we hear both good and bad reports... > > thanks. > > oddsock > At 02:29 PM 8/21/2005, you wrote: > >> Ok folks, we are getting ready for version 2.3 of icecast and have >> built an RC1 distribution. We encourage everyone to try out this new >> release and provide us feedback. Please report all bugs to >> http://bugs.xiph.org >> >> Here are the details : >> >> Source Distribution: >> http://downloads.xiph.org/releases/icecast/icecast-2.3.0.rc1.tar.gz >> Source RPM: >> http://downloads.xiph.org/releases/icecast/icecast-2.3.0.rc1-0.src.rpm >> Win32 Binary: >> http://downloads.xiph.org/releases/icecast/icecast2_win32_v2.3.0_rc1_setup.exe >> >> >> New Features >> # Streaming support for ogg speex, ogg flac, ogg midi >> # intro file support - per mount settable >> # on-demand relays, global and per-relay settable >> # fallback to file, extends on the intro file handling. >> # new mount-level settings >> 1. public, type/subtype, genre settings, stream description, >> 2. stream url, stream name, bitrate (override what is sent from the >> source client) >> 3. mp3 metadata interval >> 4. on-[dis]connect scripts can be stated per-mount, invoked at >> source start/stop and take 1 arg which is the mountpoint. >> # New URL listener authenticator .included is an example php-based >> application that can be used in conjunction with the url authenticator >> to manage a simple subscription-based broadcast. >> # HTPasswd authenticator uses in-memory structures now. >> # On demand files now can be fed through an authenticator >> # Update to admin/web xslt interface >> >> Fixes >> # real/helix works >> # win32 access log correct >> # stats client is stable now (curl -X STATS http://admin@host:port/) >> # show mountpoints on stats that are inactive but have an active fallback >> # more updates over HUP possible >> >> Note that we with regard to the new URL authenticator, we will be >> providing a demonstration application which can be used to manage a >> basic subscription-based offering. This application is not included >> in the RC, but will be included in the official release (or if we do >> another RC it will be included in that)... >> >> - Icecast Development Team >> >> >> _______________________________________________ >> Icecast mailing list >> Icecast@xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > > > > _______________________________________________ > Icecast mailing list > Icecast@xiph.org > http://lists.xiph.org/mailman/listinfo/icecast
Quick question on 2.3RC1... I am running a network of Icecast-kh51 servers in a master/slave configuration. On the central server, I run two instances of Icecast, one on port 8012 and one on port 8010. All of the sources connect to port 8010. The instance of Icecast on port 8012 has max listeners set to 1, and has a bunch of <slave-host> entries for all the slave hosts (including itself on port 8010), sort of a load-balancer. Listeners connect to the master server on port 8012 and get redirected to a slave server on port 8010. Each slave host is configured so that its master server is the master server on port 8010, and each slave server has a <slave-host> entry listing the master server on port 8012 (the "load balancer"). This slave-host entry on the slaves theoretically sends a listener back to the load balancer if it has no more listeners slots available. I really like the way this configuration works. Is it possible to replicate this in 2.3RC1? I know that some of the master/slave functionality has changed but I can't figure out if it is possible to get the same load balancing type of configuration I currently have. Also, it would be ideal if I could keep the current ports (where the sources feed to and where listeners connect) if at all possible. Thanks, Dave
On Wed, 2005-08-24 at 14:01, Joel Ebel wrote:> I have some questions related to fallback-to-file though. The > fallback-to-file mounts seem to show up on the server status page. Is > there a way to hide them? I don't really want people connecting to them > directly, or really even knowing they are there. With ezstream I just > created a <mount> section and made it hidden. Maybe I should try that. > it might still work.added to svn> This doesn't really affect me, but I'm curious about the behavior. If > you have an ogg or mp3 in the webroot, you used to be able to just > download it and play it. Now, it seems that if that file is configured > as a fallback then you can't just download it anymore. If you specify > the path to that file, you just get it streamed to you. Is there no way > to just download that file anymore if it's configured as a fallback? > This is probably a design consideration, but I'd like to understand the > reasoning. I'd sort of expected for you to be able to download the file > if you accessed it directly, but have it streamed if you were to > fallback to it. I'm sure there's a reason, but I'd be interested in > knowing it.with previous fallback setups, a new listener can fallback if the requested mountpoint is not active at the time. To allow for this, a specified fallback to file acts as a streaming source with no stream queue data, only intro file like data. This way it fits in well with the fallback/fallback-override mechanism. The data rate should be plenty but it will loop. To provide the named file like a normal download and a fallback you need to refer to the file by different names, so a copy or link should be ok. karl.
On Wed, 2005-08-24 at 18:46, Dave Pascoe wrote:> Quick question on 2.3RC1... > > I am running a network of Icecast-kh51 servers in a master/slave > configuration. On the central server, I run two instances of Icecast, > one on port 8012 and one on port 8010. All of the sources connect to > port 8010. The instance of Icecast on port 8012 has max listeners set > to 1, and has a bunch of <slave-host> entries for all the slave hosts > (including itself on port 8010), sort of a load-balancer. Listeners > connect to the master server on port 8012 and get redirected to a > slave server on port 8010. Each slave host is configured so that its > master server is the master server on port 8010, and each slave server > has a <slave-host> entry listing the master server on port 8012 (the > "load balancer"). This slave-host entry on the slaves theoretically > sends a listener back to the load balancer if it has no more listeners > slots available. I really like the way this configuration works. > > Is it possible to replicate this in 2.3RC1? I know that some of the > master/slave functionality has changed but I can't figure out if it is > possible to get the same load balancing type of configuration I > currently have. Also, it would be ideal if I could keep the current > ports (where the sources feed to and where listeners connect) if at > all possible.The registration mechanism needs improving especially with on-demand relays in the setup. so no it won't be merged into 2.3. karl.