After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 644289 - mplayer started via action freezes up afer short time
mplayer started via action freezes up afer short time
Status: RESOLVED FIXED
Product: filemanager-actions
Classification: Other
Component: general
3.1.x
Other Linux
: Normal major
: ---
Assigned To: Nautilus-actions Maintainer(s)
Nautilus-actions Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2011-03-09 09:06 UTC by scape
Modified: 2011-03-11 14:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description scape 2011-03-09 09:06:49 UTC
I have an action defined which starts mplayer like it's supposed to. But after about 30 seconds mplayer freezes up completely and needs to be killed with SIGKILL.


Example Action:
Path: /usr/bin/mplayer
Parameters: %F
Working directory: %d
Mimetypes: video/*

Everything else is left at default values. I tried all the different execution modes to no avail.
Comment 1 Pierre Wieser 2011-03-09 09:42:52 UTC
Hi,
Thanks for your interest to Nautilus-Actions.
May I suppose you are using last 3.1.1 version ?
Comment 2 scape 2011-03-09 09:51:03 UTC
Yes, I'm using 3.1.1
Comment 3 Pierre Wieser 2011-03-10 00:32:39 UTC
The bug is confirmed, though I only can reproduce it with mplayer, while totem and vlc work fine.

Not sure whether this a problem with g_spawn_async_with_pipes vs. g_spawn_async, or with mplayer, but I hope to release at least a work-around for the next week-end.
Comment 4 Pierre Wieser 2011-03-11 00:50:14 UTC
As a first sort of work-around, using mplayer with "-quiet" option prevents the process to hang.

According to the manual:

-quiet   Make  console  output less verbose; in particular, prevents the status 
         line (i.e. A:   0.7 V:   0.6 A-V:  0.068 ...) from being displayed.  
         Particularly useful on slow terminals or broken ones which do not
         properly handle carriage return (i.e. \r).

The second sort of work-around I am currently testing is to only use g_spawn_async_with_pipes when the display of the outputs is requested. So that, Normal execution mode would only use g_swpan_async which does not exhibit this bug.
It happens that gedit used to spawn its processes this way (see [1]).

With this second work-around, unfortunately, the "DisplayOutput" execution mode for mplayer will be only available with "-quiet" option.

[1] http://www.koders.com/c/fid89189BEC6C1CE649EDC918731CF607A4CDE56F19.aspx?s=g_spawn_async_with_pipes#L796
Comment 5 Pierre Wieser 2011-03-11 14:59:29 UTC
See the latest 3.1.2.
Regards
Pierre