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 402863 - Rhythmbox interferes with suspend and hibernate
Rhythmbox interferes with suspend and hibernate
Status: RESOLVED DUPLICATE of bug 596573
Product: rhythmbox
Classification: Other
Component: Plugins (other)
0.9.7
Other Linux
: Normal critical
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 547418 552969 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-01-31 16:07 UTC by Sebastien Bacher
Modified: 2009-10-09 23:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastien Bacher 2007-01-31 16:07:12 UTC
That bug has been opened on https://launchpad.net/ubuntu/+source/rhythmbox/+bug/78038

"Rhythmbox has decided it wants to control suspend and resume.

I want suspend to pause the music, and resume when I awaken my laptop - and I think this is pretty darn reasonable, as hitting the suspend button is unlikely to be accidental.

Screenshot attached.
...
http://librarian.launchpad.net/5599557/rhythmbox.png
screenshot of error message.
...
> 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
...
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."
Comment 1 William Jon McCann 2007-01-31 17:41:00 UTC
Richard, shouldn't inhibiting only stop the idle actions (on inactivity) and not the explicit (button or widget initiated) ones?
Comment 2 Richard Hughes 2007-01-31 17:53:04 UTC
Well I figured both - imagine the scenario of a software update calling Inhibit() and you really don't want to suspend during a rpm transaction, even if you have pressed the button.

Maybe we need a better inhibit call, i.e. Inhibit and ReallyInhibit?

Comment 3 William Jon McCann 2007-01-31 18:10:47 UTC
I guess basically my thoughts haven't changed since
http://bugzilla.gnome.org/show_bug.cgi?id=334809#c4
http://bugzilla.gnome.org/show_bug.cgi?id=334809#c6

Basically, if I click suspend or close my laptop it is because I really mean it.  If I am listening to music then it should stop where it is and resume later.  If I am updating software then it should stop and resume later.  etc.  Anything that doesn't do that we should fix.  Maybe we'll lose a CD but so what - that's my fault.

If g-p-m doesn't suspend when I want it to then that is bad - as this bug suggests.
Comment 4 Havoc Pennington 2007-01-31 22:47:19 UTC
As far as method names, just make them long, no harm in that. 

InhibitAutoSuspend()
InhibitAllSuspend()

or something.
Comment 5 Henry Gomersall 2007-01-31 23:46:23 UTC
I'd like to bring to your attention the following bug I filed:
http://bugzilla.gnome.org/show_bug.cgi?id=384545

I expect the solution may well be applicable to that also.
Comment 6 Jonathan Matthew 2007-02-01 10:09:54 UTC
I've been thinking of it in terms of 'hard' or 'soft' inhibit.  This distinction might be one of those things that only makes sense if you already understand it, though.
Comment 7 Richard Hughes 2007-02-01 19:32:15 UTC
2007-02-01  Richard Hughes  <richard@hughsie.com>

	* data/gpm-inhibit-test.glade:
	* docs/dbus-interface.html:
	* docs/dbus-interface.xml:
	* docs/icon-scheme.html:
	* docs/index.html:
	* src/dbus/gpm-dbus-inhibit.xml:
	* src/gpm-inhibit-test.c: (dbus_inhibit_gpm),
	* src/gpm-inhibit.c: (gpm_inhibit_find_cookie),
	* src/gpm-inhibit.h:
	* src/gpm-manager.c: (gpm_manager_is_inhibit_valid),
	* src/gpm-powermanager.c: (gpm_powermanager_inhibit_auto),
	* src/gpm-powermanager.h:
	* src/gpm-self-test.c: (test_inhibit):
	Convert the new API to InhibitAuto for auto-suspend prevention and
	InhibitManual for stuff like RPM transactions and BIOS flashes.
	The old manager inhibit API has been converted to the InihibitAuto
	style to fix #402863
	Update the self test program, the inhibit example program and the
	documentation.

This means if you use g-p-m svn then rhythmbox does the right thing.
Comment 8 Johannes Berg 2007-02-23 21:23:08 UTC
We've done some real hard work in the kernel to get alsa and drivers to properly suspend/resume the stream so whatever application was using the card can function properly over suspend.

Maybe I just want to suspend and resume playing afterwards? I don't think rhythmbox should make *any* policy decisions.
Comment 9 Jonathan Matthew 2008-08-12 13:24:10 UTC
*** Bug 547418 has been marked as a duplicate of this bug. ***
Comment 10 Murray Cumming 2008-08-13 07:57:21 UTC
(In reply to comment #7)
> 2007-02-01  Richard Hughes  <richard@hughsie.com>
[snip]
> This means if you use g-p-m svn then rhythmbox does the right thing.

I guess this requires some change in rhythmbox, because it's over a year later and rhythmbox still prevents explicit (non-auto) hibernation.

Comment 11 Murray Cumming 2008-08-13 08:28:41 UTC
Increasing severity to critical because this can lead to data loss, for instance when Rhythmbox prevents hibernation due to low-battery (automatically, or when closing a laptop lid because you know that the battery is low).
Comment 12 Jonathan Matthew 2008-08-14 12:22:59 UTC
(In reply to comment #10)
> I guess this requires some change in rhythmbox, because it's over a year later
> and rhythmbox still prevents explicit (non-auto) hibernation.

Not as far as I can tell.  It appears that g-p-m dropped the distinction between inhibiting automatic and manual actions; I'm not sure what semantics the Inhibit request is supposed to have now, but that's all there is.
Comment 13 Jonathan Matthew 2008-09-20 06:19:02 UTC
*** Bug 552969 has been marked as a duplicate of this bug. ***
Comment 14 Jean-François Fortin Tam 2008-09-20 13:48:34 UTC
bug 552960 describes something a bit trickier. There are "voluntary" vs "automatic" suspend scenarios, but inside the voluntary one, there are two subscenarios: hotkey/menu request vs lid close. Copy-pasting:

Rhythmbox should only inhibit "timed" suspend/hibernate actions, not "manual"
actions such as pressing the "suspend" button on a keyboard. 

It SHOULD make an "exception" however, when closing the lid of a laptop, as this
might be a special case (ie: I want to put the laptop in a bag while still
listening to music). However, when I press the suspend hotkey (or access it
through gnome's menus), I really "mean" suspend.

So, to summarize:
- when the user starts the action manually:
-- if lid closes: inhibit
-- if not a lid event: do not inhibit
- when the computer requests automatically (idle): inhibit
Comment 15 Jonathan Matthew 2009-04-23 06:45:57 UTC
*** Bug 579908 has been marked as a duplicate of this bug. ***
Comment 16 careta 2009-04-26 20:31:43 UTC
I am a new Rhythmbox user, changed from Banshee.

I prefer Rhythmbox on all aspects, except that it won't me let hibernate when the music is playing. This is really annoying. 

Right now my Pulseaudio (0.9.10) has a problem with hibernate, sometimes I have to restart the apps playing music, but I prefer that to let Rhythmbox decide for me when can I or cannot suspend! I disabled the plugin after unhiding it in gconf-editor, but I don't understand you have you hidden it?
Comment 17 Jonas Häggqvist 2009-05-08 13:39:29 UTC
I don't understand the arguments in comment #14 (Jean-François Fortin Tam). I would say that the usual intention when closing the lid is to perform whichever action was configured in the power management settings. If you *do* want to inhibit suspend in that case, because you want to play music in your bag (?!) I'd say you should use the inhibit panel applet (that exists, right?) because you're most likely a minority and everyone else will suffer overheated laptops if Rhythmbox inhibits suspend for lid-close events, whereas you'll just suffer having to press a few buttons if it doesn't.
Comment 18 Jean-François Fortin Tam 2009-05-09 00:15:53 UTC
Explaining the "lid close" part of comment #14: I use my laptop as a portable music player (with headphones). I put it in my messenger bag when walking or using the public transit. It blanks the screen and saves energy (and space). This worked well with older not-power-efficient laptops (with pentium M CPUs, for example), and it works even better now that I have a passively cooled netbook (Mini 9) which produces little heat.

I would REALLY REALLY hate losing this feature. If I wanted the thing to actually suspend when putting it in my bag/closing the lid, I would either:
- have stopped the music (is it that hard? ;)
- disabled the rhythmbox power management plugin (if I didn't want rhythmbox to interfere at all)
- pressed the actual power button instead of closing the lid (not implemented; this is what this bug is about, "soft" vs "hard" inhibit)
Comment 19 Manuel Amador (Rudd-O) 2009-05-09 02:38:03 UTC
I don't think that's a bug either.  Many many people want to close the lids of their laptops when music plays so that they can listen to music while saving power or transporting the laptop from one place to another (think "car" scenario).  I have personally witnessed that.

I think it is a very reasonable default to inhibit suspend as long as music is playing, that this inhibition be removed when the last song plays, and that this should be presented to the user as a menu option, defaulting to ON, titled "Play music even with the lid closed" or "Do not suspend machine while music is playing" -- naturally this option ought only be displayed if the computer has a LID.  Note that the oposite -- i.e. an option defaulting to OFF titled "Stop music when the lid is closed" because that would make the music stop even if the machine is not suspended by policy -- and that does not make sense.

All in all, that's my view.  What we need to do is find out what the expectations of actual Rhythmbox users are, or dictate a policy and have an option for the large minority that doesn't agree with the default one.
Comment 20 Jonathan Matthew 2009-05-09 05:21:37 UTC
If there's going to be a setting like that, it doesn't belong in rhythmbox at all.  It's not an application preference, it's a system preference.

I've changed the gconf defaults so the power manager plugin is not active and not hidden, at least until we can make it behave itself.  The plugin apparently needs to be rewritten to use the gnome-session 2.26 dbus interface some time soon, which might solve some problems.
Comment 21 ulrik sverdrup 2009-08-15 11:56:28 UTC
Why cannot rhyhtmbox turn off Inhibiting, or give an option for it, until it works as it should? Too many times do I close the lid and find my computer warm in the morning, playing music all night (quietly, since it was evening). This is absolutely not good for my computer and gnome-power-manager and rhythmbox are collaborating in the totally wrong way here.. not to save power or computer lifetime but the opposite.
Comment 22 Jonathan Matthew 2009-08-15 13:26:00 UTC
The plugin is disabled by default, as I said in comment 20.
Comment 23 Jonas Häggqvist 2009-08-15 13:48:16 UTC
I think I will restate this, as it seems on a re-read I did not make myself terribly clear, and I'm not sure what the plan for the future is:

* Inhibiting on lid-close by default will lead to heat-damaged laptops for those that don't expect it.
* Not inhibiting on lid-close by default will lead to slight inconvenience for those that want it.

I think the rational choice is pretty clear.
Comment 24 ulrik sverdrup 2009-08-23 14:21:05 UTC
Sorry for the fury, thank you for taking the conservative and sane approach as outlined by Jonas.

One useful (for me) improvement in this corner would be to use the power management plugin to Pause Rhythmbox when suspending. Mostly you don't expect rhythmbox to play when unsuspending, and not all sound hardware handles suspending with playing sound very well.
Comment 25 Jonathan Matthew 2009-10-09 23:32:19 UTC

*** This bug has been marked as a duplicate of bug 596573 ***