I don't think that this problem can disappear by itself. After restarting it will be back sooner or later.
In fact, I have no problem such as cuts or dropdowns when relaying an external stream. The only trouble is that I get a log file polluted by thousands of identical lines signaling a "buffer overrun" problem. => up to 6 GB (!) for a log file after a couple of days in operation (10 to 20 lines every second in addition to normal events logged...) May be this would be solved in reducing the verbosity level of liquidsoap. But in case of real troubles, It'll be more difficult to get accurate data to understand what's going wrong... Fred Facundo Suárez <[email protected]> a écrit : > Well, very thanks for your explanation. > > If i understood ok, the problem may disappear by itself, i mean, when > server accepts data as usal, the error message will dessapear. Is it > like this ? > > In many cases, as i said, shutting down the script, and starting > again, the problem is gone. > > Thanks. > > 2011/12/28 David Baelde <[email protected]>: >> Hi guys, >> >> This is a difficult problem. The HTTP protocol has no mechanism for >> synchronizing streams. The client may be sending data too fast >> compared to the rate at which the data is played back by liquidsoap. >> This is the likely explanation for what you're experiencing. >> >> Since liquidsoap uses the same synchronization as liquidsoap, there >> may be less problems when connecting two liquidsoaps over HTTP, but >> it's not guaranteed: it still depends on the internal clocks of the >> involved machines. In fact, I have this kind of problem with my own >> station which runs liquidsoap on a remote low-power server with a >> pretty bad clock. >> >> I don't know of any easy solution for the moment. Two ways of >> improving the situation, though, are (1) making the HTTP input drive >> the liquidsoap clock, which only helps if the clock is not already >> driven by the soundcard or such, or (2) create a device for >> synchronizing clocks between two liquidsoap instances, if possible >> re-using technology to that effect, but this wouldn't help with >> clients not using that technology. If anybody is interested in >> studying/implementing either solution, I'd be happy to help. >> >> Cheers, >> -- >> David >> >> ------------------------------------------------------------------------------ >> Write once. Port to many. >> Get the SDK and tools to simplify cross-platform app development. Create >> new or port existing apps to sell to consumers worldwide. Explore the >> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join >> http://p.sf.net/sfu/intel-appdev >> _______________________________________________ >> Savonet-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/savonet-users > > > > -- > Facundo Suarez > Neuquen - Capital > suarezjf -> twitter > > () ascii ribbon campaign - contra el coreo html > /\ www.asciiribbon.org - contra adjuntos propietarios > ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
