On Fri, May 28, 2010 at 10:03:26PM +0200, Ilja Sekler wrote: > I didn't try the second stream, but I can confirm the report by Giorgio > for the first one with revisions prior to r31254. r31255 (I omitted > r31254 in my tests) plays the stream fine, but there are warnings > > Cache not filling! > > every few seconds. Many other streams I tried don't trigger this warning > and play impeccably. This is when the cache becomes full and MPlayer has to wait more than ca. 100 ms for any new data to arrive. You are only lucky enough to not here this when there is a lot of buffers (also for the uncompressed audio) involved. It's an indication that something is going wrong, in this case you probably should be chosing a larger cache prefill value (or larger cache size, has the same effect since prefill is in percent of overall size). > PS: Sorry for nit-picking, there is a misprint on line 581 in > stream/cache2.c, I get warning > > Cache no responding! Yes, I had noticed that before, I just forgot to commit it :-) > (should be "Cache not responding!") when playing pcm stream of Hauppauge > PVR250 from /dev/video24 with -cache option, the command line is > > mplayer -af volume=12:1 \ > -cache 2048 \ > -demuxer rawaudio -rawaudio rate=48000:channels=2 /dev/video24 > > The pcm stream itself is played without issues. This is probably related to some commands like setting up the channel take a huge amount of time. Currently MPlayer can't distinguish between this and an actually hanging cache. So far I think those printouts are doing the job they're intended to do, however I'm not fully decided on that yet. (note that I mostly added them because it's not the first time the cache process was killed and users were left scratching their head what is going on - this should at least give some hint).
