Hi Peter, That's a long mail... I'll try to answer carefully even though it's a late and busy time, as a "thank you" for your very serious feedback on the alsa error issue :p
On Sat, Dec 4, 2010 at 9:23 PM, Peter Retep <[email protected]> wrote: > Please let me know how you feel about this proposals, but important to me, > if you have any idea how I could dynamically set streams as input sources. I have answered your propositions below. The bottom line is that while some requests are valid (and should be submitted as tickets for us to do when we find some time) most are unlikely to be satisfied, and my viewpoint is that you shouldn't be using playlist here. I'm not quite sure what to propose... For example I'm a bit reluctant to say source.dynamic() because it's still a bit new. Also it's not user-friendly but it's not a big concern: the idea is that we provide simple solid building blocks, used in scripting libraries to derive more complex, custom blocks. I know that it's frustrating but I often have to turn down proposals to "make liquidsoap smarter". Smarter tools can be more confusing: being smart is sometimes less important than being predictable. Also, we have limited development time (these days I barely do any coding on liquidsoap) and it's more important that we focus on simple robust components than too many features that may become unmaintainable. Coming back to your problem, we'll try to find a suitable solution. But what do you need specifically? The ability to play a list of streams and files? Waiting for the streams to stop to go to the next file? Do you loop when the list is over, like a playlist? Perhaps, when you need a stream there is no other item in the list? Could it work with a fallback of a re-configurable input.http (this might be already possible) and a normal playlist? > From my POV, the playlist function in using "normal" mode could be used > as a much simpler interface than using queues with polling status, > checking ids, dropping them in case of changes and swapping queues. I totally agree that queues are difficult to use. But we'll see soon some user-defined scripting mechanisms that wrap queues in ways that makes them more usable for common workflows. Now the specific points... > 1) > I did not get it run if playlist file contains a continous stream > (maybe because stream download never ends?) Yup, playlists play requests and requests are only meant for finite files. I can't remember all the reasons right now, but in any case it wouldn't be an easy change: streams just don't fit the current infrastructure for requests. > 2) > I noticed, that playlist function does not resolve remote playlist files > liquidsoap > 'out(playlist(reload=20,mode="normal","http://localhost/request.m3u";))' That should work, but not if request.m3u contains file URIs. (Also, obviously, what request.m3u refers to as local files may not be remote once you've downloaded request.m3u on the liquidsoap host.) > Support of unwrapping remote playlists and putting these entries as single > entries into liquidsoap's playlist would be really cool. I agree that it would be cool. We've actually discussed similar extensions but it's not as simple as it seems. You can file a ticket, but I don't promise anything -- it doesn't look like a big priority. > 3) > playlist reload does seem to be executed during playing out a playlist entry. > This makes it impossible to switching between entries that are (endless) > streams. Invalid since entries are not supposed to be endless streams. > 4) > If playlist is reloaded then it starts from the beginning. > This means if I add an entry in "normal" playmode then the playlist will > start from scratch again. I guess we could detect if the playlist doesn't change at all after reloading... > At least for "normal" mode it would be fine, > if playlist would not be restarted in case that only entries after the > current playing have changed. But you're already asking for more :p and the check will become more expensive... There's a point where it might backfire if we do too much stuff on potentially very long lists. Anyway, please file a ticket if you really need it in the end, and we'll think about it carefully. > 5) > A good idea could be a explicit playlist reload function to trigger the > reload externally from the server interface. It's already there, check the available server commands. It's called <playlist_id>.reload. We also have a command for getting/setting the current playlist URI. > 6) > Support of "file:///" protocol would be helpful. Many browsers support it. Good point, file a ticket and we'll do it very easily. > This could provide a common handling for URLs and files. We already got one, files are really seen as special URLs. Requests are all about URLs (URIs in fact). But they are still different from streams. > 7) > Maybe same cause as 1) following did not work for me. > request.create("http://piradio.de:8765/radio";) Same, yes. Best regards, -- David ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
