mplayer stops ogg streaming, repeating "Cache not filling!"

ogg123 works very well with the same stream (by manually extracting the stream URL from the playlist). This is definitely an mplayer bug.

On Tue, Sep 28, 2010 at 23:56:52 (CEST), Horst Schirmeier wrote:

> Public bug reported:
>
> Binary package hint: mplayer
>
> Since upgrading to Maverick beta (mplayer went to
> 2:1.0~rc4~try1.dsfg1-1ubuntu1), playing the ogg stream from
> http://www.eldoradio.de/broadcast/ogg.pls fails after a few minutes with
> a repeated "Cache not filling!" message. mplayer does not recover from
> this state. For testing purposes, I removed ~/.mplayer/ completely.

I cannot reproduce this problem on i386 on the stream

url=http://eldoweb.eldoradio.de:8000/160.ogg

can you please check if this happens with both

mplayer -demuxer lavf $url

and

mplayer -demuxer ogg $url

?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

I can reproduce the problem with "mplayer -demuxer lavf $url" on amd64 (failure after ~185s). This demuxer is also being chosen by default.

"... -demuxer ogg" seems to work fine, no problems within the last 15 minutes.

interesting. can you please also try to playback that stream with 'ffplay' from the 'ffmpeg' package?

FWIW, it works for me, but -demuxer lavf did so as well, so I'm curious.

Sorry -- works fine, too :-)

More interestingly, I cannot reproduce the original problem ATM. Maybe this also depends on weather and moon phase conditions ...

Okay, full moon is over. I again get reproducible failures with mplayer (-demuxer lavf), and ffplay also stalls after about 3 minutes (it did three times in a row now):
179.22 A-V: 0.000 s:0.0 aq= 0KB vq= 0KB sq= 0B f=0/0

I am getting a similar problem trying to dump a real player stream. The command I am using is:

mplayer -nojoystick -nolirc -prefer-ipv4 -playlist http://www.bbc.co.uk/mediaselector/4/asx/b00vc2d8/iplayer_intl_stream_wma_uk_concrete -ao pcm:file="/home/ian/mp3/$FILE.wav" -vc dummy -vo null

This is from the BBC Listen Again service, so the stream url will only be valid for 7 days it anyone wants to test it.

This works fine on Lucid, but I get "Cache not filling" errors when using Maverick. I don't know if it's related to this similar error:

http://www.spinics.net/lists/mplayer-users/msg02781.html

I found on the mplayer mailing list.

Ian.

Doh! Posted the wrong link for the mplayer bug. It should have been: http://<email address hidden>/msg08061.html

Ian.

I have the same issue when listening to my mpd (music player deamon) which run a http stream server. In fact when mpd change the music (next track on the playlist for example). mplayer broke the stream while with -demuxer ogg its OK.

I got caught by this bug in mplayer, the cache not filling! messages caused my internet radio stream recordings to die after about 25 minutes. The number of messages caused the mplayer session to die. My sessions are initiated by a cron job and additionally the session resides is a detached screen session (screen -dmS sessionname commandname) . The reason behind this is mplayer needs a terminal to bind to for it's standard out. For me, this problem began after I upgraded from Lucid to Maverick. I have found a work around to the problem, this involves launching mplayer with the -nocache switch. This obviously stops it using a cache and then no messages about the cache not filling are emitted during the streaming session. One side effect to be aware of is mplayer doesn't spawn a child process with this switch. I had to modify my parent python program to only check for one process not two for a successful mplayer session to start. My mplayer command looks like this: mplayer -endpos 01:00:27 -quiet -nocache -vo null -vc dummy -ao pcm:waveheader:file=~/record/3rrr/work07Nov/MHR07Nov10.wav.wav http://media.on.net/radio/114.m3u. My mplayer version is reported as MPlayer 1.0rc4-4.4.5. Hope this helps others with a work around while the bug is being worked on.

Cheers, Hotmanta