Hi, Thanks for your responses guys and sorry for my absence. I was in a different universe for couple days ;)
> The only solution for now is to add a "min" buffer parameter, which > adds an end of track when buffer becomes lower than this value.. Is this "min" a parameter to http.input? When I add it I get the error message: At line 7, char 34-35: cannot apply that parameter because the function (at line 7, char 18) has no argument labeled "min"! > I agree with you, David: azerty88, could you tell us more on how > exactly you expect transitions from live to music to happen? Do you > wait for the network connection to drop? At this moment I'm just preparing myself to setup a online radio station, so I'm testing what can be done and how things can be handled with liquidsoap. It's hard to tell at this moment how final demands will look like, but I thought I could use a fade out transition when for example a DJ played last song and stopped streaming. So yes I think that end of connection could be the indicator when the transition should happen. Since, as you said, it's hard to tell the difference between end of transmission and network failure, I could imagine that if a live show is expected to start at 12:00 and end at 14:00 o'clock then any break between 12:00 and 14:00 is a network failure and a break near to 14:00 is end of a live show. Would it be possible to use that assumption somehow to deal with the problem? Dnia 11 czerwca 2012 6:56 Romain Beauxis <[email protected]> napisał(a): > 2012/6/10 David Baelde <[email protected]>: > > On Sat, Jun 9, 2012 at 5:15 PM, Romain Beauxis <[email protected]> wrote: > >> In normal conditions, breaks are added by the stream decoders. Also, > >> #remaining in sources/generated calls the buffer's remaining method, > >> which takes breaks into account. > > > > Right, breaks are taken into account one level deeper, I had missed it. > > > >> The solution I was proposing before was to add a break when the buffer > >> gets under a certain threshold. I think that this is the only way to > >> have some kind of transition when feeding ends, since we cannot > >> differentiate network lags and proper end-of-stream.. > > > > I find this a bit ugly because the purpose of buffering is to hide > > network lags, which is defeated if we add such meaningless breaks. > > Another option, also a bit but in a different way, is to have a mode > > where we always advertise the current remaining amount of data, and > > never -1. This way, the transition could kick in without a break, and > > possibly be interrupted if more data is received in the buffer... > > > > Anyway, we still don't have a confirmation that azerty88 is interested > > in having transitions on network lags. I need to run some tests to see > > if things do work fine for normal stream termination, and then think > > some more. > > This is all correct. At the end of the day, the problem is simple -- > and I have a feeling it has already been brought up in the past: there > is no way to distinguish between a temporary failure and an expected > end of connection. > > If you add to this that we cannot backtrack in time, it explains why > transitions fail with live source: when network disconnection is > detected, it is already too late to compute a proper transition.. > > I agree with you, David: azerty88, could you tell us more on how > exactly you expect transitions from live to music to happen? Do you > wait for the network connection to drop? > > Romain > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
