rhythmbox interferes with suspend

Thanks for your report. Your idea might get more attention and have the possibility of being implemented if you would submit a specification for this.

You should first check whether it already exists at the Ubuntu specs page (https://launchpad.net/distros/ubuntu/+specs) in Launchpad. If that is the case, feel free to contact the drafter of that spec about your comments/suggestions. Otherwise you can start writing a spec following the steps described in
  https://wiki.ubuntu.com/FeatureSpecifications.

That is a new plugin, it should probably be listed by the interface though, you can stop it by changing the /apps/rhythmbox/plugins/power-manager/active gconf key to false

Cody, do you really think that a small bug like that one is a candidate for a specification? We don't want thousand of specifications registred for every small request made to launchpad

On Fri, 2007-01-05 at 11:42 +0000, Sebastien Bacher wrote:
> That is a new plugin, it should probably be listed by the interface
> though, you can stop it by changing the /apps/rhythmbox/plugins/power-
> manager/active gconf key to false
>
> Cody, do you really think that a small bug like that one is a candidate
> for a specification? We don't want thousand of specifications registred
> for every small request made to launchpad

Interesting, its not listed by the interface - ah, because it has the
'hidden' flag set.

I'll disable it for now.

BTW, I chatted with upstream on IRC, they agree this is a bug, that the
power-manager plugin is not right yet.

Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

I've opened a bug upstream about that: http://bugzilla.gnome.org/show_bug.cgi?id=402863

Do you still get that bug? The new gnome-power-manager has changes for that and the problem might be fixed now with them

This still occurs in an up-to-date (rhythmbox 0.11.5) Hardy Beta. Pressing the power button just causes g-p-m to display the message "Music Player has stopped the policy action from taking place: Playing." I would argue that the importance is significantly more than "Low", due to the inability to shutdown/restart/suspend/hibernate while listening to music. Personally I find this to be a great annoyance which didn't exist in Gutsy, that will affect all users of rhythmbox who make changes to the power state of their computer (estimated to be large).

Please kill this behaviour.. listening to music should NOT block suspend.. maybe video should but not audio

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

KillerKiwi wrote:
> Please kill this behaviour.. listening to music should NOT block
> suspend.. maybe video should but not audio

Nothing should block a user-initiated suspend except the possibility of
permanent damage to hardware.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH8sK00F+nu1YWqI0RAuvrAJ9H+byORS6XvnT9qTj3vEGZh30oZgCeP/hU
NYFVas4mQv1ak51S+fRUbco=
=G4mr
-----END PGP SIGNATURE-----

> Interesting, its not listed by the interface - ah, because it has the
> 'hidden' flag set.
>
> I'll disable it for now.

Robert Collins said this above on 1/5/2007, and I agree with his decision. However it looks like in the new version it needs to be disabled again.

Personally, my strong recommendation here would be to:

 1) not make this 'hidden' by default (gconf flag: /apps/rhythmbox/plugins/power-manager/hidden).
 2) not make this 'active' by default (gconf flag: /apps/rhythmbox/plugins/power-manager/active).

Why something that interferes with the user's explicit choice in g-p-m is active by default, and not only that but HIDDEN by default is foreign to me. I understand the use-case for this plugin, but it should not be active by default; a user seeking a special exception to his or her settings should, I would reason, have to actually make a special exception, via this plugin. The burden should be put on confused and irritated users to figure out why their explicit options in g-p-m are not being followed, it should be put on the users who want special and non-standard behavior. Additionally, making it not hidden will also allow such curious users to enable it easier. This could then go in the Ubuntu FAQ as something similar to: "How to have your PC ignore suspend requests when playing music".

What does everyone think?

Banshee is also affected by this bug, but it's not a plugin - Banshee just always does this when music is playing. I second Mike's description of the problem, above.

I think we need a distinction between active power management: power button, lid close, menu option; and passive power management: a timeout expired. Active power management should not be affected by dbus calls that override suspend unless you change a system setting which defaults to 'off'. Passive power management overriding should have a system setting as well, and it might make sense to default that to 'on'.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cory Dodt wrote:
> I think we need a distinction between active power management: power
> button, lid close, menu option;

You might also want to include "battery power critically low" in this list.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH/kB50F+nu1YWqI0RAi4BAJ97fAeutPYQ6wiVH0gW+5jQGGziSACffq13
HgUcINiKj8OE9QU3FoFEmHI=
=4hWi
-----END PGP SIGNATURE-----

This bug also stops hibernation on critical battery level, i.e. is a source of potential data loss & hardware damage.
Status should be high or critical [exclamation marks].

Where I said above "The burden should be put on confused and irritated users..." I definitely meant should NOT be put on them, sorry for that terrible typo!

And arand, that is a good point that I had not considered. I will bump it up to Medium for now for reasons previously described, and after further discussion, potentially increase it.

Arand, have you confirmed that it stops hibernation on critical battery level? My machine is set to shut down on critical battery, and I tested it yesterday (rhythmbox 0.11.5-0ubuntu4, g-p-m 2.22.1-1ubuntu4) and although I could not manually shut down while music was playing, when it got to critical levels it was still able to shut down fine.

As such it isn't High/Critical as you say (at least for that reason). Though let me know if you have evidence to the contrary.

Yes, when my battery goes to critical, the message stating that it will hibernate pops up and shortly thereafter a message 'hibernation stopped' shows, and if I let it run for a short while longer nothing happens (I then plug in AC to avoid crash).

(I have set gpm to act on higher percentages since I have an old battery, and disabled [use_time_for_policy], this for auto-hibernation to work at all).

I'm attaching two cropped screenshots of these messages.

Hi Arand, I have confirmed that you are correct! If you have g-p-m set to shutdown on critical battery, it works fine even with music playing in Rhythmbox. However, the "suspend" and "hibernate" options do not work, as Rhythmbox denies the request. I will move the importance to High, as you are correct, data loss is very possible in these scenarios, if not hardware damage.

Again, all that needs to be done is to disable the "power-manager" plugin in Rhythmbox by default, which was done in Gutsy for Rhythmbox 0.10 anyway, making this far from controversial. It looks like this is a simple case of a regression that just got lost in the 0.10 -> 0.11 upgrade for Hardy.

why should a shutdown create hardware damage? and there is no need to call every bug a regression, this behaviour is not constructive

Hi Sebastien. I said "if not hardware damage", as in, potentially. It seems possible that a firmware update, write operation, or some other process that needs warning to return a device to a safe state, could be immediately interrupted without warning. That *could* be bad.

Also, I don't recall calling every bug a regression. Notice the fourth post where Robert says he disabled the power-plugin in Rhythmbox (as it was in Gutsy for Rhythmbox 0.10). In Rhythmbox 0.11 it isn't disabled. That seems like a classic case of a regression. I think it is VERY constructive to draw attention to that fact, since we already know how to fix it, since it was fixed in Gutsy, and can apply the same thing to the new version of Rhythmbox in Hardy.

If I am missing something regarding either of these issues please do explain it to me.

Regression - "the appearance of a bug which was absent in a previous revision", right? Why wouldn't this be a regression?

And it was me who started shouting about hardware damage, maybe a bit undue, granted that, but for example doesn't some lithium batteries take full discharges very badly? And interrupted devices as Mike pointed out.

Then again, data loss is bad enough, isn't it?

This bug was fixed in the package rhythmbox - 0.11.5-0ubuntu6

---------------
rhythmbox (0.11.5-0ubuntu6) hardy; urgency=low

  * debian/rhythmbox.gconf-defaults:
    - don't activate the power manager option it breaks suspend for example
      (lp: #78038)

 -- Sebastien Bacher <email address hidden> Mon, 21 Apr 2008 14:59:43 +0200

Thanks so much Sebastien for helping squash this bug! I think you have saved some data with this one, and definitely frustration from all the upgraders who would have otherwise not been able to shutdown with music playing.

I am also very glad to see that you took my suggestion and made the plugin not hidden by default either. This should make it easier for people to discover it and use it for a fair use case of listening to music when closing the lid, while normally having suspend or hibernate occur for this action. Once http://ubuntuguide.org/wiki/Ubuntu:Hardy becomes existent, I can put an entry there.

However, Sebastien, do you know if there is a more important underlying bug? It is my understanding that Rhythmbox shouldn't be allowed to deny the suspend/hibernate on critical battery. Have we discovered a deeper issue, or not?

you can read the GNOME bug about those extra questions about suspend, that is a different issue though

It was duped upstream as a dup of https://bugzilla.gnome.org/show_bug.cgi?id=596573