mplayer doesn't start immediately

Hi,
I confirm that behaviour on Hardy.
On my system, it seems to hang at
xscreensaver_disable: Could not find XScreenSaver window.
GNOME screensaver disabled

After strace-ing the process, i could find that it's waiting for a child process
which is, according to the 'ps' command :

sh -c dcop kdesktop KScreensaverIface isEnabled 2>/dev/null | sed 's/1/true/g' | grep true 2>/dev/null >/dev/null

In fact, i could confirm that launching manually this very command delays 5 sec before exiting on error (ERROR: Couldn't attach to DCOP server!).

I'm not sure why mplayer on Ubuntu should be concerned with dcop, as i run on the Gnome-based Ubuntu (having some KDE-related libraries installed, in order to use some KDE apps).

I'm unsure where the bug comes from, but there should be some testing on whether it's needed to run this dcop command, or, at least, run it in the background so it doesn't delay the starting on error.

Hi again,
After investigation, it happens that the source of the problem is that the screensaver-shuttingdown code (which is compiled-in on the packaged mplayer) probes for the kde screensaver by calling dcop. This should work on "pure" gnome desktop, as this command doesn't exists and returns quickly, and also on kde desktop, as this command run and return quickly. Yet, on a Gnome desktop with KDE libs installed on the hard disk, the "dcop" binary exists, although no dcopserver may be running.

Checking for a running dcopserver before calling dcop should fix the problem

Suggested fix is : from upstream libvo/x11_common.c file, changing

kdescreensaver_was_running =
(system
             ("dcop kdesktop KScreensaverIface isEnabled 2>/dev/null | sed 's/1/true/g' | grep true 2>/dev/null >/dev/null")
             == 0);

to

kdescreensaver_was_running =
(system
             ("pidof dcopserver && dcop kdesktop KScreensaverIface isEnabled 2>/dev/null | sed 's/1/true/g' | grep true 2>/dev/null >/dev/null")
             == 0);

Note that you can workaround the whole problem by disabling the xscreensaver-disabling code.
Either add
stop-xscreensaver=0
to the ~/.mplayer/config

or reverse this setting in /etc/mplayer/mplayer.conf

I recall the first time I faced this problem was when I had installed kubuntu and then uninstall some parts of it. It should be related to KDE as you said.

This is an old bug, it existed an hardy and feisty (I don't remember further).
This is not a regression as said in bug 292928.

Davide, is this still an issue for you?
Benjamin, you set this to "in progress" and suggested a few solutions, but you didn't attach the patch and didn't assign this to yourself. Are you actively working on this? Are the solutions you proposed still valid?

This not seems an issue anymore for me (on Jaunty).
I have installed both kde3 libs and a complete kde4 desktop, no problems at all.

I still experience this - note that it does not occur if any kde application has been started since login, as the kde application will start up dcopserver.

This bug was fixed in the package mplayer - 2:1.0~rc3+svn20090426-1ubuntu1

---------------
mplayer (2:1.0~rc3+svn20090426-1ubuntu1) karmic; urgency=low

  * Switch to debian packaging for the mplayer package
  * New upstream release, LP: #336697, #260918, #246675, #243453, #74282
  * Fixes security issues: CVE-2008-5616, LP: #308939
  * many flv fixes LP: #73271, #347021
  * Build and install mencoder
  * Bump epoch

mplayer (1.0~rc3+svn20090426-1) unstable; urgency=low

  [ fabrice ]
  * Introduce the mplayer-nogui package, that does not depend on GTK+

  [ Reinhard Tartler ]
  * new upstream svn version based on the 1.0rc3 branch
  * various cleanups and refactoring in debian/rules
  * no longer remove mencoder.c: It does hardly contain any "dangerous"
    or patented code. Instead:
  * strip libavcodec similar to how its done in the ffmpeg package. This
    brings the patent policy of the mplayer and ffmpeg package in debian
    finally in sync. c.f. the comments and the "discussion" in #522373.
  * install upstream's version of binary_codecs.sh

mplayer (1.0~rc3+svn20090405-1) unstable; urgency=low

  * New upstream version. Track the 1.0rc3 release branch for now.
  * remove 50_r28803_segfault_print_int.patch, merged upstream.
  * no longer remove the TOOLS subdirectory from the upstream source.
  * make get-orig-source rule actually work.
  * disable musepack support. Closes: #476384
  * completely delegate handling of /etc/mplayer/mplayer.conf to
    dpkg. This change removes also all debconf templates and reduces
    package complexity.
  * move .gbp.conf to debian/gbp.conf
  * cleanups in debian/rules: prefer external debhelper helper files
  * enhance upstream Makefile to install gmplayer manpages
     - implement as quilt patch, submitted upstream
     - debian/rules: make use of the added rules
  * use dh_prep instead of dh_clean -k
  * bump Standards-Version to 3.8.1

mplayer (1.0~rc2+svn20090303-7) unstable; urgency=low

  * various cleanups in debian/rules.
  * as a side effect, DEB_BUILD_OPTIONS set to noopt no longer works. It
    really needs to be implemented in ./configure instead of weird hackery
    in debian/rules. patches welcome.
  * run 'make distclean' only of config.mak exists.
  * remove debian/control.mplayer* variants.
  * don't --enable-debug on mipsen. This hopfully fixes the FTBFS on mipsen.

mplayer (1.0~rc2+svn20090303-6) unstable; urgency=low

  [ A Mennucc1 ]

  * use ./configure flags to dynamically link FFmpeg,
    delete patch 30link-system-ffmpeg.patch

  [ Reinhard Tartler ]

  * cleanup debian/rules: use --enable-debug on all architectures but mips.
    in order to fix a FTBFS. This results in making the -dbg package on mips
    useless. If you are interested in having a usable mplayer-dbg package on
    mips, please try enabling that switch in debian/rules and send us your
    buildlog!
  * run 'make distclean' only of config.mak exists
  * cleanup debian/rules: remove unnecessary clean statements

mplayer (1.0~rc2+svn20090303-5) unstable; urgency=low

  * debian/control : move docbook-xml,docbook-xsl,xsltproc from
    Build-Depends-Indep to Build-Depends, since they are needed to run
    config...

work around for gnome app user:

Delete or move dcop from /usr/bin/dcop