Hi David, thanks for your answer!
I have one remaining problem which did not occur in the past now I am using Liquidsoap 1.0.0-beta+svn (trunk/liquidsoap@rev8193). If I use server scripts (scheduler) to change the url , changing the url will not work anymore, until I stop the source and wait some seconds, before restarting. Problem is that I do not know how long I have to wait after stop to ensure that source is really down. I assume that the server stop command does not wait until connection is closed, so next start command will use the same source as before. Eventually shutting down the source sometimes takes longer than my sleep command. If there is no sleep/wait between stop and start the URL is set to the new value, but I see no source changes in the logs and audio output does not change. case 1 ) using a script like this works: source.url http://stream/source1 source.play source.stop sleep(3) source.url http://stream/source2 source.play case 2 ) same as case 1 but without sleep does not work. case 3) With last checkout I used from february (svn) It worked still by setting the url and trigger the play method. source.url http://stream/source1 source.play source.url http://stream/source2 source.play This does not work anymore. >> 1) reseting an source URL >> How could I reset the secondary URL empty in this case? > Currently liquidsoap crashes if the URL is invalid. That's not a good > behavior but it's easily avoided: just set the URL to > http://nowhere/nothing and it should be fine. To avoid the active > polling (not very costly on such a stub address, but still) also do a > <input>.stop. input stop function works, I can also check URLs HTTP availability before setting it, so I can work around this. Thanks for this hint! >> 2) checking source URL status > For knowing if it's connected or not we have an internal flag, and I > could easily make it available as a command. However, a quick look at > the code didn't suffice to convince me that this flag still makes > sense -- it doesn't seem to be updated. Moreover, one of the planned > changes to input.http() and others would automatically bring that kind > of feature. ok, I am looking forward to changes within input.http. Currently I have just no possibility to know what URL is currently playing, since url could be set to another value, than the source is currently playing. If there are changes planned I can wait for this. >> (or any HTTP error codes 4xx which could give a hint what is going wrong >> like (not found, unauthorized) >> seesection 10.4 Client Error 4xx at >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html ) > For that, the log file is a natural solution. But I guess it could be > more convenient to have a command indicating the last HTTP answer > code. > > Could you please create a new ticket for those two features? I will do right after sending this mail. >> 3) HTTP authorization >> >> How could I request URLs that are protected by authorization, like .htaccess >> user@password:http://domain.com > I use this already, the syntax is http://user:[email protected]/foobar I did not test it, but expected it in the same way as you wrote. Thats fine! ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
