Triode Wrote: > You could try changing the "-cache 128" to a larger number as this > should mean mplayer does more buffering > > Danco - as for the mac - there is definately something wrong here with > mplayer copies remaining - this only seems to have started with the > latest OSX. I'm afraid that without access to OSX we can't really help > diagnose other than asking you to instrument mplayer.sh and letting us > know what is going on...
Sorry, what do you mean by "instrument mplayer.sh"? I'll be happy to try things, but I need guidance as to what to change and what to log. I'm fairly certain that when I play a "listen again" program and it plays to the end, then the two copies of mplayer (and I think you said that there are supposed to be two copies) then close down. They stay around, though, if one stops the program before its end (which I often do as the Listen Again may continue past the actual end of the program), or if the dropouts finally lead to the stream stopping. Unlike bilko2, when I get the choppiness the chunks still seem to come out in the right order. I see that changing the cache number didn't help him. I wish I could remember exactly when I started having this problem. It certainly is comparatively new. I would try a newer version of mplayer if I knew what version of the cook codec is the right one, and where to find it. As I mentioned elsewhere, I strongly suspect that the issue is some process (perhaps even a copy of mplayer) taking up all the CPU for a brief moment. Is there any effective way of checking this, either with the Mac's GUI or from the terminal. Using Activity Monitor only gives the CPU usage at 0.5 second intervals, which may be too long. -- danco _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
