On Thu, Jan 20, 2011 at 07:49:57PM +0100, David Coppa wrote: > On Thu, Jan 20, 2011 at 5:46 PM, Landry Breuil <lan...@rhaalovely.net> wrote: > > On Thu, Jan 20, 2011 at 05:02:55PM +0100, David Coppa wrote: > >> On Thu, Jan 20, 2011 at 4:54 PM, David Coppa <dco...@gmail.com> wrote: > >> > On Thu, Jan 20, 2011 at 4:43 PM, Landry Breuil <lan...@rhaalovely.net> > >> > wrote: > >> > > >> >> spoke too fast, there's a regression for clients of http output. Dunno > >> >> what mpd > >> >> 0.16 outputs, but after the end of a track, instead of playing the next > >> >> one mplayer goes into a loop : > >> >> > >> >> Cache not filling! > >> >> Cache not filling! > >> >> > >> >> 0.15.12p5 works fine. > >> > > >> > Is this with ogg vorbis? > >> > >> Or, more probably, it's related to this: > >> > >> http://musicpd.org/mantis/view.php?id=3149 > >> > >> http://git.musicpd.org/cgit/master/mpd.git/commit/?id=18b30b50197261a8f062f44b5e8b24b21fb2b280 > > > > I'm not sure.. mpd itself still runs fine, the libao output still plays, > > it's just the http client that fails. If i restart it, it resumes > > streaming fine. And yes, this is with ogg vorbis encoding, same setup: > > Can you please check if this happens with both: > > mplayer -demuxer lavf $url > > and > > mplayer -demuxer ogg $url > > If the latter works fine... maybe it's mplayer's fault
The latter indeed works fine. But still, mplayer + default lavf demuxer _works_ with mpd 0.15.12, so that's a regression. Landry
