mplayer blocks on dcop for several seconds at startup
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
kdelibs (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
mplayer (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: mplayer
mplayer (2:1.0~
sh -c dcop kdesktop KScreensaverIface isEnabled 2>/dev/null | sed 's/1/true/g' | grep true 2>/dev/null >/dev/null
However, if KDE is not in use, dcop spends several seconds polling the (nonexistent) socket:
uname({sys="Linux", node="rika", ...}) = 0
connect(3, {sa_family=AF_FILE, path="/
close(3) = 0
rt_sigprocmask(
rt_sigaction(
rt_sigprocmask(
nanosleep({1, 0}, {1, 0}) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
uname({sys="Linux", node="rika", ...}) = 0
connect(3, {sa_family=AF_FILE, path="/
close(3) = 0
rt_sigprocmask(
rt_sigaction(
rt_sigprocmask(
[loop]
Because of this, mplayer startup is delayed by several seconds.
mplayer should either not block on dcop (ie, handle it asynchronously), or at least offer a config option to disable kscreensaver integration. Alternately, dcop should offer a no-retry option, and mplayer should make use of said option.
This is a regression from hardy, in which mplayer startup was essentially instantaneous.
Also note that running dcopserver is a usable workaround for this problem, but the root cause should be fixed.
Added kdelibs4c2a (4:3.5.10-0ubuntu6) as this dcop polling/retry behavior may be a regression(?) from hardy.