Package: moosic
Version: 1.5.4-3
Severity: important
Subject: 'moosic stop' no longer kills mpg123 child process
Package: moosic
Version: 1.5.4-3
Severity: important
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages moosic depends on:
ii python 2.5.2-1 An interactive high-level object-o
ii python-support 0.8.3 automated rebuilding support for P
Versions of packages moosic recommends:
ii mpg321 0.2.10.4 mpg123 clone that doesn't use floa
-- no debconf information
(In addition to the above, since mpg321 is not in fact being used in the
failing case: this is with version 1.4.3-2 of mpg123.)
Normally, when moosic receives its 'stop' command, it kills the child
process it spawned for playback of the currently playing file. Likewise,
when it receives its 'pause' command, it puts the process to sleep much as
Ctrl-Z might do. Earlier this week, this was working as it had been the
entire time I've used the program. Sometime yesterday afternoon, I found
that the behaviour was different.
At present, mpg123 is a symlink (via /etc/alternatives) to one of the
/usr/bin/mpg123-{alsa,esd,nas,oss{,-i486}} shell scripts. Whether or not
this was previously the case, I do not know. Those shell scripts are simple
one-liners which merely launch /usr/bin/mpg123.bin with the appropriate '-t'
option for that type of audio output.
Yesterday afternoon, when I attempted to stop playback of an MP3 file being
played via moosic, it did not stop; moosic's playlist was updated as if the
stop had been successful, but playback continued.
After a little research with 'ps aux -H', I found that the apparent cause is
that moosic had in fact killed only its own child process - the mpg123 shell
script - and that, rather than causing that shell script's binary child
process to also be killed, this had caused the child to become a 'top-level'
process and continue running uninterrupted.
I do not recall testing, but I would expect that that the same type of
misbehaviour would occur with the 'pause' command.
I have worked around this problem on my own system by replacing the "call
this to play MP3 files" line in ~/.moosic/config with an invocation of
'mpg123.bin -t oss' rather than simply to 'mpg123', preventing the spawning
of a grandchild process to confuse matters; still, this seems mildly
hackish, and in any case will not prevent others from having the same problem.
I am not entirely certain where the cause of this problem lies. I can see
how it could be in any of moosic (the program), mpg123 (the package), or
even bash (the program). I have been updating packages on a fairly regular
basis recently, but none of those have been among those updated since the
last time I remember using moosic without this problem; the only possibly
related packages which I know *were* updated in that time are python et al.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages moosic depends on:
ii python 2.5.2-1 An interactive high-level object-o
ii python-support 0.8.3 automated rebuilding support for P
Versions of packages moosic recommends:
ii mpg321 0.2.10.4 mpg123 clone that doesn't use floa
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
