Bug#699864: mplayer2 from experimental doesn't work with smplayer

Reinhard Tartler siretart at gmail.com
Wed Mar 27 06:26:30 UTC 2013


On Tue, Mar 26, 2013 at 11:53 PM, Ricardo Villalba
<smplayer.dev at gmail.com> wrote:
> I'm the developer of smplayer. I've just found this post:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699864#14
>
> Are you seriously considering to replace smplayer by smplayer2? Is
> this for real?

I was seeking for opinions. Your input is very appreciated!

> smplayer2 is based on an old version of smplayer (0.8.0) while the
> current version of smplayer is 0.8.4. It lacks a lot of things, like
> the support for youtube. You would be dropping a whole year of my
> work.

I was not aware of that. Thank you ver clarifying this.

> smplayer2 works better with mplayer2 because it's intented to be a gui
> for mplayer2, so if mplayer2 removes the -fontconfig option they
> remove as well in smplayer2 and that's it. But smplayer tries to work
> with both mplayer and mplayer2, so I can't remove that option that
> easily. By the way I've just compiled smplayer2 from git and it can't
> work at all with the regular mplayer:
>
> Unknown option on the command line: -gapless-audio
> Error parsing option on the command line: -gapless-audio
> MPlayer svn r34540 (Ubuntu), built with gcc-4.6 (C) 2000-2012

Okay, so switching would, just as I expected, trade one bag of
incompatibilities with another one. Now we need to decide which bag is
easier to handle for us. Your explanation is invaluable useful for
this decision.

> The problem of the -fontconfig option was fixed in smplayer a lot of
> months ago (last november). It's not completely fixed because of the
> way mplayer2 is packaged in ubuntu (I guess is the same in debian).
> The problem is that the mplayer2 executable is called exactly the same
> as mplayer: "mplayer". So smplayer can't know what application it is
> until it's run for the first time. So when the first file is played it
> still can fail with the -fontconfig problem because smplayer assumes
> it's using mplayer, but once it knows it is actually mplayer2 it won't
> use the -fontconfig option anymore.
>
> In windows I fixed this problem very easily, in my packages I've
> renamed mplayer.exe to mplayer2.exe, so smplayer knows the actual
> application before running it, so the -fontconfig error never happens.
> For me it would be easier if mplayer2 in linux had also a different
> executable name.

Would it be possible to have smplayer detect the version of the
mplayer binary in some other way, such as by looking at some
environment variable or looking at some file in the system? I would
guess that the environment variable approach might be portable and
allow easy testing during the development of smplayer. Moreover, it
would allow me to locate the best location in the source-code to hook
a distro-specific check into.

What do you think?

-- 
regards,
    Reinhard



More information about the pkg-multimedia-maintainers mailing list