> On Thu, 20 Mar 2003, Todd Poston wrote: > > > Just a follow up to this, Geoff... > > True, that is how you'd do it when you know what *n* number of > > streams/files you wished to serve at the time the client d/l's the > > playlist. There are cases when you may wish to dynamically change > > what the client hears (live radio for instance, or > maintenance, etc.) > > without requiring the client to manually reconnect. Redirects > > would/could be handy _IF_ clients supported them universally. Alas. > > Well, you could dynamically produce the playlist with some > scripting language like ASP or PHP. Would achieve the same thing. > > Geoff.That's right. But you still have the issue of changing the source after they have connected - regardless of what is in a playlist. The client just stays connected the whole time and doesn't have to do anything. Fortunately icecast can do this. :) Granted, this feature won't be used by most users, but I think it is entirely a worthwhile feature. I guess the ability (within the code) needs to be there anyway so that mountpoints can have fallbacks, which I would think does the same thing. But it is nice to have dynamic control of which sources serve which mountpoints. Todd --- >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-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.
Just a follow up to this, Geoff... True, that is how you'd do it when you know what *n* number of streams/files you wished to serve at the time the client d/l's the playlist. There are cases when you may wish to dynamically change what the client hears (live radio for instance, or maintenance, etc.) without requiring the client to manually reconnect. Redirects would/could be handy _IF_ clients supported them universally. Alas. Icecast supports moving clients to new streams (very cool BTW), and that serves the same purpose - although not as flexible as redirects could be (if the "new stream" was on a different Icecast instance (or computer) for example). Cheers and keep up the great work. Todd PS - Michael, you send a lot of early morning emails so watch you don't burn yourself out!!! ;) Oh and FWIW, I offer up my C# knowledge/coding/time if it could be of use in some aspect to you all. Although I doubt it would be, I wanted to throw it out there anyway.> If you want to play 1 stream then play another, surely it's > enough to simply place 2 items in the playlist file that you > send to the client. It works and it's supported. > > Geoff.--- >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-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 Thu, 20 Mar 2003, Todd Poston wrote:> Just a follow up to this, Geoff... > True, that is how you'd do it when you know what *n* number of > streams/files you wished to serve at the time the client d/l's the > playlist. There are cases when you may wish to dynamically change what > the client hears (live radio for instance, or maintenance, etc.) without > requiring the client to manually reconnect. Redirects would/could be > handy _IF_ clients supported them universally. Alas.Well, you could dynamically produce the playlist with some scripting language like ASP or PHP. Would achieve the same thing. Geoff. <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-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.