Your message dated Mon, 24 Oct 2016 16:20:37 +0200
with message-id 
<CAE6_+UeDQyTQqxMZNBu4YX1=gaaimQAmU35=4uhx_gue2w5...@mail.gmail.com>
and subject line Re: Bug#781752: quodlibet: hangs when jackd is stopped
has caused the Debian Bug report #781752,
regarding quodlibet: hangs when jackd is stopped
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
781752: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781752
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: quodlibet
Version: 3.3.1-1
Severity: normal

Dear Maintainer,

Using jackd as the sound server, when jackd is closed (either manually, or as
the result of a timeout) the quodlibet program that was using it freezes.  In
the console quodlibet produces an error message of:

0:00:37.241103899 25707 0x7f959006cf50 ERROR             jackclient 
gstjackaudioclient.c:35:jack_log_error: JACK died - calling shutdown handler

At that point, menus no longer function and the app can not be killed with a
SIGTERM.

This can be reproduced by starting jackd, starting quodlibet, begin playing a
song, pause playing a song, kill jackd. At that point quodlibet is frozen and
the UI is completely unresponsive.

Attempted to restart jackd: quodlibet does not reconnect.

Attempted to kill quodlibet with SIGTERM: has no effect (UI remains frozen,
  process doesn't die).

Attempted to kill quodlibet with SIGKILL, and restart: successful in getting
  back to listening to music.

If the audio sink goes away, quodlibet should be as well behaved as other
programs (chromium, iceweasel, mpd, etc) in that music playback may not work
but the UI should still be responsive and allow the user to close the
application.

First found the issue with quodlibet v3.2.2-1, but attempted to use v3.3.1-1 in
order to verify that the behaviour still exists.

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (901, 'testing'), (800, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages quodlibet depends on:
ii  exfalso                                             3.3.1-1
ii  gir1.2-gst-plugins-base-1.0                         1.4.4-2
ii  gir1.2-gstreamer-1.0                                1.4.4-2
ii  gstreamer1.0-plugins-bad [gstreamer1.0-audiosink]   1.4.4-2.1+b1
ii  gstreamer1.0-plugins-base                           1.4.4-2
ii  gstreamer1.0-plugins-good [gstreamer1.0-audiosink]  1.4.4-2
ii  gstreamer1.0-plugins-ugly                           1.4.4-2+b1
ii  python                                              2.7.9-1

Versions of packages quodlibet recommends:
ii  dunst [notification-daemon]  1.1.0-1
ii  gir1.2-gtksource-3.0         3.14.1-1
ii  gir1.2-keybinder-3.0         0.3.0-1
ii  libgpod4                     0.8.3-1.1+b1
ii  media-player-info            22-2
ii  notification-daemon          0.7.6-2
ii  python-dbus                  1.2.0-2+b3
ii  python-feedparser            5.1.3-3
ii  python-pyinotify             0.9.4-1
ii  udisks                       1.0.5-1+b1

Versions of packages quodlibet suggests:
ii  gstreamer1.0-plugins-bad  1.4.4-2.1+b1

-- no debconf information

--- End Message ---
--- Begin Message ---
Fixed in GStreamer (gstreamer1.0-plugins-good) since 1.8.3 which is in testing.

--- End Message ---

Reply via email to