On Sat, Mar 01, 2003 at 07:09:24PM +0000, Karl Heyes wrote:> On Sat, 2003-03-01 at 18:41, Adam Scriven wrote: > > Is there anywhere I can go to get detailed information on how this works? > > I'm wondering about passing information back and forth, for example, or > > if there's anyway to collect information like the audio program they're > > listening with, or perhaps passing "state" information back and forth. > > The script playlist runs a program (can be anything executable) and that > just sends to it's standard output a series of filenames (typically > absolute paths) of ogg files to play. Each filename is read and is used > to find a file to play, anfter that has finished then another filename > is read.Actually, from the tests that I've done, ices only uses the first song the script outputs. I have a script that right now is very simple, it bascially just prints out two songs to play, each "line" ending in \n. What happens is, it plays the first song, then re-runs the script to get the next song, but since the script just prints out lines, it re-prints the first line first again, and ices logs this: "EROR playlist-builtin/playlist_read Cannot play same file twice in a row, skipping" It never reads the second "line" outputted from the file. So, without any state information being passed back and forth from audio program<->icecast<->ices, the only way left to track the state of the script is to read/write external files. That seems a bit inelegant to me, but that's MNSHO, and maybe I'm screwing something up. :)> ices has no way of telling you whats been used to play streams as that > is inside icecast, there is practically no feedback from icecast. It > sounds like you want something from icecast itself.Yeah, I hadn't realised that when I asked the question. I'd forgotten icecast was there, it's working so well. (Loaded up the server and forgot about it. Isn't that how they're supposed to work? :) ) So, is there anyway to make icecast and ices communicate that information, or will I need to just track that information myself with external files or something? Thanks for all the help! Adam --- >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.
Adam Scriven <scriven@lore.com> said:> On Sat, Mar 01, 2003 at 07:09:24PM +0000, Karl Heyes wrote: > > On Sat, 2003-03-01 at 18:41, Adam Scriven wrote: > > > Is there anywhere I can go to get detailed information on how this works? > > > I'm wondering about passing information back and forth, for example, or > > > if there's anyway to collect information like the audio program they're > > > listening with, or perhaps passing "state" information back and forth. > > > > The script playlist runs a program (can be anything executable) and that > > just sends to it's standard output a series of filenames (typically > > absolute paths) of ogg files to play. Each filename is read and is used > > to find a file to play, anfter that has finished then another filename > > is read. > > Actually, from the tests that I've done, ices only uses the first song the > script outputs. > I have a script that right now is very simple, it bascially just prints out > two songs to play, each "line" ending in \n. > What happens is, it plays the first song, then re-runs the script to get the > next song, but since the script just prints out lines, it re-prints the first > line first again, and ices logs this: > "EROR playlist-builtin/playlist_read Cannot play same file twice in a row,skipping"> > It never reads the second "line" outputted from the file. > > So, without any state information being passed back and forth from audio > program<->icecast<->ices, the only way left to track the state of the script > is to read/write external files. That seems a bit inelegant to me, but that's > MNSHO, and maybe I'm screwing something up. > :)No, you're exactly right. The script module is relatively primitive - it was intended mostly as a somewhat useful, but simple proof-of-concept. The intent was to eventually (optionally) have stateful in-process scripts (using perl or python, as ices 0.x allows) as another playlist module. I never got around to writing those - maybe someone (you?) is interested in doing so? I think the ices 0.x code for that should be adaptable to ices2 without too much difficulty. <p>>> > ices has no way of telling you whats been used to play streams as that > > is inside icecast, there is practically no feedback from icecast. It > > sounds like you want something from icecast itself. > > Yeah, I hadn't realised that when I asked the question. I'd forgotten icecast > was there, it's working so well. (Loaded up the server and forgot about it. > Isn't that how they're supposed to work? :) ) > So, is there anyway to make icecast and ices communicate that information, > or will I need to just track that information myself with external files or > something? >The communication between ices and icecast is essentially (apart from some optional connection negotiation stuff at the start) one-way only. 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-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 Sun, Mar 02, 2003 at 01:44:59AM -0000, Michael Smith wrote: <much snippage, sacrificed to the bandwidth gods>> No, you're exactly right.Wow, I've never been exactly right before! :)> The script module is relatively primitive - it was intended mostly as a > somewhat useful, but simple proof-of-concept. The intent was to eventually > (optionally) have stateful in-process scripts (using perl or python, as ices > 0.x allows) as another playlist module.OIC, Ok. That makes sense, then. I guess that explains why most of the documentation still says "basic" is the only playlist type supported.> I never got around to writing those - maybe someone (you?) is interested in > doing so? I think the ices 0.x code for that should be adaptable to ices2 > without too much difficulty.I would love too, but I'm not good enough with C, and I've got far too many hobbies/things-on-my-plate as it is. :( I have some ideas for how to get around the simple system (using state-files, as I mentioned before). Basically, I'm interested (as I'm sure thousands of other people are) in writing an internet-radio type of thing, with web interface and whatnot. I haven't found one of the available ones that I like, really. As an aside: For some reason, I always tend to fall back on doing my own thing, recreating the wheel basically. Most of the software written by others, while excellent, doesn't have the specific features/interfaces that I want, and I've always thought it was, I dunno, rude maybe, to ask for features on someone else's project when all I could offer in return was to use the software, and bug test it if that was requested. I guess I just want a slightly different wheel, so I have to design it myself. <more snippage. must appease the bandwidth gods afterall>> The communication between ices and icecast is essentially (apart from some > optional connection negotiation stuff at the start) one-way only.Yeah, that's what I had thought. Thanks for the confirmations and info, Mike! Adam --- >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.
Ok, I've got one more question. I've got my stream largly working... I don't have any of the external, web-based stuff necessary to build lists, ETC... but the streams themselves are working quite well. My question is, using the script playlist option.. how can I tell ices that the playlist is over? I know I can just keep sending the same result over and over, but that seems rather ineligant. Is there a "magic" string, or perhaps a null string that will tell ices to give up right away, or do I need to just repeat the last entry in the playlist over and over until ices gives up? Thanks again! Adam --- >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.