Comment 11 for bug 650670

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