On 2012/04/14 15:29, Iskren Chernev <iskren.cher...@gmail.com> wrote: > I think a better approach would be to try and reconnect to the stream > (especially if its non seekable -- I'm not 100% if that happens only > for radios, or some stupid https serving mp3 may also be), all the > time, or maybe after a long pause. > > I just got a rough understanding of how the input and decoder layer > work, but I'm not sure if the change should be introduced inside > input_curl or on a higher level.
We have a bug report for this, but I havn't gotten around to fix it yet. What we need is two things: - the input plugin API should get a new method, maybe called pause(), which suspends buffering for relevant plugins. - for radio streams (remote, not seekable), the pause() method could tell its caller "don't bother keeping me open", and some code a few layers up will close it and reopen on resume Max ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
