[MPlayer-users] Re: memleak in cvs

[Arpi]

Hi,

> Read it.  I posted all the relevent information it said i should.  
> 
> mplayer -v 
> MPlayer CVS-020819-18:20-2.95.4

rotfl
i mean output of mplayer -v [your options of playing these files]

> It does seem to only show up when using the gui.  But are you saying
good.

> that the gui is not part of mplayer?  
yes
at least it's not part of mplayer core.
it's a frontend for the commandline mpalyer, but uses internal path to
control the player instead of the external slave-mode way.
the gui is written by one person, Pontscho, i don't know that code so i
can't fix its bugs. please send a detailed step-by-step HOWTO-REPRODUDCE
text so he can reproduce and fix the problem.
i've tried the gui but i can't see it leaking memory.

> I find it funny that you consider the gui not a part of mplayer.  there
why?

> are several audio outputs and video outputs and now there are two user
> interfaces, some may be experimental or buggy but it's still mplayer.
tehre are at least 3 frontends for the commandline mplayer.
one of them is included in cvs, others are not.
they are frontends, not paert of the core code. the core code works without
them and don't need them. they are optional, and under heavy development.
actually the gui included in cvs is called gmplayer not mplayer.

> It's obvious that the gui is now an mplayer feature just as much as your
since when?

> interface.  There have to be some core developers using the gui in order
some? since when?

> I could be wrong though and if none of the core developers consider the
> gui part of mplayer to be part of mplayer (and the site says it is) then
> maybe they should take it out and the gui should be developed as a
> frontend like every other project that doesn't want to deal with a gui
it's developed separated, but it's hosted on teh same server and CVS as the
core code. actually it's the part of the mplayer _project_, but not
the mplayer _core_code_.

> has.  someone else then is responsible for the gui and gui problems are
> completely separate from the backend program.  In mplayer's case the gui
> is not simply a frontend so it is mplayer.   And the memory usage i'm
> seeing must be caused by gui hooks because i dont see how gtk code can
> be consuming the memory as video is playing.  I work with gtk and i dont
> see mplayer doing anything that could be doing that.  But because the
> gui is a part of mplayer it's unclear as to if code inside gui hooks
> where the gtk code is attached to the player or in code for gtk use that
> is going insane (file progress info etc?).  It doesn't pay to ignore
> huge new parts of code to your project as a developer.  

actually gtk is not completely used by teh gui. 
the gui is Xlib-based, uses its own skinned widgets, gtk is only used for
popup menus like playlist and file selector.

anyway i'm not a gui coder, i don't know teh gui code at all, just teh
interface to mplayer. it's a frontend but it uses 'internal wires' to the
core instead of sockets/pipes.

but, back to the topic.
either try to locate where the bug is, or send a detailed, usefull bugreport
and/or a howto-reproduce description to this list or the gui author.
just flaming the developers about their dislike-gui is not a help.

mplayer is still a commandline player and it is its native, primary
interface. every other way of controlling (including guis, slave mode etc)
are experimental and not really supported things.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu