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

[Horst Schirmeier]

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.

The Lucid Lynx version of mplayer did not have this problem. Other randomly picked ogg streams do not have the same problem, nor do non-ogg streams.

$ rm -rf ~/.mplayer/; mplayer -prefer-ipv4 -playlist http://www.eldoradio.de/broadcast/ogg.pls
Creating config file: /home/hsc/.mplayer/config
Resolving www.eldoradio.de for AF_INET...
Connecting to server www.eldoradio.de[129.217.204.226]: 80...
Cache size set to 320 KBytes
Unknown entry type NumberOfEntries=1
Unknown entry type Version=2
MPlayer 1.0rc4-4.4.5 (C) 2000-2010 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing http://eldoweb.eldoradio.de:8000/160.ogg.
Resolving eldoweb.eldoradio.de for AF_INET...
Connecting to server eldoweb.eldoradio.de[129.217.204.226]: 8000...
Name : eldoradio* lebt mit dir. 160 kbit. www.eldoradio.de
Genre : eldoradio
Website: http://www.eldoradio.de
Public : no
Bitrate: 160kbit/s
Cache size set to 320 KBytes
Cache fill: 12.50% (40960 bytes)
libavformat file format detected.
[ogg @ 0x26f2140]Estimating duration from bitrate, this may be inaccurate
[lavf] stream 0: audio (vorbis), -aid 0, Zur Zeit keine Online-Playlist [Audio Boutique]
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, s16le, 160.0 kbit/11.34% (ratio: 20000->176400)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis)
==========================================================================
AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
Cache not filling! of 0.0 (unknown) 0.5% 10%
Cache not filling!
Cache not filling!
Cache not filling!
Cache not filling!
...

This Fedora user seems to experience the same problem:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1349
See also (a mplayer SVN revision without the problem is mentioned!):
http://www.pubbs.net/201005/mplayer/53530-mplayer-users-freeze-with-radio-streams.html

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: mplayer 2:1.0~rc4~try1.dsfg1-1ubuntu1
Uname: Linux 2.6.35.6 x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Tue Sep 28 23:13:18 2010
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: mplayer

[Horst Schirmeier (horst)]

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

[Reinhard Tartler (siretart)]

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

[Horst Schirmeier (horst)]

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.

[Reinhard Tartler (siretart)]

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.

[Horst Schirmeier (horst)]

Sorry -- works fine, too :-)

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

[Horst Schirmeier (horst)]

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

[Ian Barton (ian-manor-farm)]

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.

[Ian Barton (ian-manor-farm)]

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

Ian.

[Benpro (benpro82)]

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.

[HotManta (hotmanta)]

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