From owner-freebsd-multimedia@FreeBSD.ORG Tue Mar 23 11:35:50 2004 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73D4C16A4CE; Tue, 23 Mar 2004 11:35:50 -0800 (PST) Received: from odot.okladot.state.ok.us (odot.okladot.state.ok.us [192.149.244.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8C1443D1D; Tue, 23 Mar 2004 11:35:49 -0800 (PST) (envelope-from root@techpc04.okladot.state.ok.us) Received: from notes9c.okladot.state.ok.us (notes9a.okladot.state.ok.us [10.36.36.31])NAA73912; Tue, 23 Mar 2004 13:35:48 -0600 Received: from techpc04.okladot.state.ok.us ([199.27.9.37]) by notes9c.okladot.state.ok.us (Lotus Domino Release 5.0.12) with ESMTP id 2004032313363301:16936 ; Tue, 23 Mar 2004 13:36:33 -0600 Received: by techpc04.okladot.state.ok.us (Postfix, from userid 0) id 6E57C5C11; Tue, 23 Mar 2004 13:35:56 -0600 (CST) To: , From: "Paul Seniura" Errors-To: "Paul Seniura" Sender: "Paul Seniura" Message-Id: <20040323193556.6E57C5C11@techpc04.okladot.state.ok.us> Date: Tue, 23 Mar 2004 13:35:56 -0600 (CST) X-MIMETrack: Itemize by SMTP Server on Notes9c/ODOT(Release 5.0.12 |February 13, 2003) at 03/23/2004 01:36:33 PM,2003) at 03/23/2004 01:36:33 PM, Serialize complete at 03/23/2004 01:36:33 PM Subject: mplayer cache problems, I think it's cross-platform X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Paul Seniura List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2004 19:35:50 -0000 Hi y'all, Finally getting caught up on CTM ports-cur deltas on this Puny Pentium2. ;) The recent update for mplayer is having problems. I must specify '-nocache' for anything to work. Or 'nocache=yes' in the ~/.mplayer/config file. Any cache size at all >= 4 will cause mplayer to hang with it not filling the cache (verbose showing): CACHE_PRE_INIT: 0 [0] 0 pre:0 eof:0 Cache fill: 0.00% (0 bytes) I can hit Esc or q to get out of this hang in a 'normal' manner. A cancel will show: MPlayer interrupted by signal 2 in module: enable_cache I compiled & installed mplayer both with RTC support and without, via /etc/make.conf . No difference. The kernel & world are at the current CTM src-cur delta levels, too (including last night's buckets CST). I am using the KDE .wav files for testing. With nocache in effect, it works, both RTC and nonRTC compiled modes. The 'play' cmd from another port works fine, too. Of course the GUIs based on mplayer are all hanging at this same spot, too. I don't know if they are specifying cache size internally. I haven't seen anyone mention this problem yet here. But it seems at least another person on another platform is having similar problems: I saw a freshly-posted msg on mplayerhq's dev list: The top part of mplayer's cmd-line mode displays: MPlayer 0.92-3.3.3 (C) 2000-2003 MPlayer Team CPU: Intel Celeron Covington/Pentium II Deschutes,Tonga/Pentium II Xeon (Family: 6, Stepping: 2) Detected cache-line size is 32 bytes CPUflags: MMX: 1 MMX2: 0 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0 Compiled for x86 CPU with extensions: MMX I'm not a member at the mplayer HQ. I'm wondering how to go about saying "me too" to their site. Assuming other FBSDers can reproduce this problem, can our maintainer report this to the mplayer HQ, please? Or should I open a FBSD PR and let it go thru channels? Thank you, -- Paul Seniura System Specialist State of Okla. D.O.T.