GNOME Bugzilla – Bug 585293
Disable computer sleep if listening to music
Last modified: 2020-03-17 08:33:13 UTC
I was listening to some sweet tunes and my computer went to sleep. I realized it was because my computer was set to go to sleep after 15 min of inactivity. I wish computer sleep (not display sleep) was disabled automatically when I was listening to music in Banshee. Other information:
It's a good idea. I worry about the (inevitable?) complaint from somebody who didn't want this. I also don't like cluttering our Preferences needlessly. Does this warrant a preference, "Inhibit sleep when playing media", that's enabled by default? Or just enable this behavior, no option?
It makes sense to me that it be enabled by default. I can't really think of a scenario where you would want to disable (i.e., not override computer sleep settings). I guess it might warrant a preference, but how about not having the preference and disabling computer sleep if music is playing and volume is not muted. Then enable the system's setting if music playback is stopped. My scenario was with a passive experience of listening to music. I image that a similar thing would happen for video. Not sure though. Might be worth a test. If this is the case, it would probably be good to disable computer sleep as well as display sleep.
(In reply to comment #2) > ...I can't really think of a > scenario where you would want to disable... How about the case in which your computer is a laptop and is not connected to the AC? It may make sense to *not* disable the sleep phase.
For me, if I'm listening to or watching something, experiencing the media takes a higher priority over battery conservation. That's why I think basing it on if some audio/video is playing and the volume > 0 because, when combined, those are a sign that the user is experiencing their media. I mention battery conservation above... but are there other reasons why someone would put their computer to sleep. Maybe there's some other risk that I'm missing by proposing this.
(In reply to comment #4) > For me, if I'm listening to or watching something, experiencing the media takes > a higher priority over battery conservation. I don't agree. I would prefer an interruption by the sleep mode than a total interruption because the battery ran out. If this is not going to include a visible-user-preference, I would only agree with a fix for this if it doesn't affect the situation in which there's no AC connection.
(In reply to comment #5) > (In reply to comment #4) > > For me, if I'm listening to or watching something, experiencing the media takes > > a higher priority over battery conservation. > > I don't agree. I would prefer an interruption by the sleep mode than a total > interruption because the battery ran out. If this is not going to include a > visible-user-preference, I would only agree with a fix for this if it doesn't > affect the situation in which there's no AC connection. > Wouldn't the OS provide the interruption with a low battery warning (~5% remaining)? I guess it might depend on the OS but I'm not sure. What if a user is watching a movie on a flight (assuming the gap between seats allows them to open the computer lid). It would kinda be a nuisance to move the mouse every so often to keep the computer alive. I could figure out how to turn off the monitor and computer sleep, but my mom (or a novice user) couldn't. Another option might be if Banshee doesn't detect an AC connection, flash a notice to the user that they may want to disable computer sleep. "OK"-ing the notice would remove it until Banshee is relaunched or the AC is plugged back in.
Good points, I didn't think about them.
At the moment, we already inhibit the screensaver if you are watching a video in fullscreen; I've though for a while that we should probably do this whenever you're playing a video, even if not in fullscreen, as long as the Banshee window is visible. Adding the inhibit-sleep when playing any media would take care of videos, too. Andres, can you do some research: does using the dbus/GNOME Power Manager InhibitSleep command actually prevent the PM from suspending when in the critical battery mode? I would imagine it ignores all inhibits in that case, but would be good to confirm.
Rhythmbox did this and it broke suspend/hibernate on critical battery, causing data loss, so we disabled it in Ubuntu. I don't know if that is a failure of GPM or Rhythmbox but it would be very crucial to test this case first. I generally agree with the overall sentiment though that if Banshee is playing media (but not just has the window visible, it has to be playing something) then it should inhibit suspend/hibernate, and if a video is playing, inhibit screensaver (but don't inhibit screensaver if only music is playing).
(In reply to comment #8) > Andres, can you do some research: does using the dbus/GNOME Power Manager > InhibitSleep command actually prevent the PM from suspending when in the > critical battery mode? I would imagine it ignores all inhibits in that case, > but would be good to confirm. You mean the DBus function "org.freedesktop.PowerManagement.Inhibit::void Inhibit(string application, string reason, out uint cookie)", right? If yes, I'll test it tomorrow, but how can I know what is critical battery mode? Is there a convention? I imagine it's below 3%?
Created attachment 138058 [details] PowerManagement options on battery power (In reply to comment #10) So, I tested this on OpenSUSE 11.0 (with these options configured), and even without using the DBus method mentioned above, I reached 0% and the computer didn't suspend/sleep. So I guess I'm being affected by some bug :( I'll test with OpenSUSE 11.1 when I have another spare moment...
Created attachment 138167 [details] PowerManagement options on battery power #2 So, now tested with this configuration, still on OpenSUSE 11.0, and the computer got suspended (to disk) after 11 minutes. I then tried inhibiting this via DBUS, with this code: org.freedesktop.PowerManagement.IInhibit inhibit = org.freedesktop.PowerManagement.PowerManagementService.Default.Inhibit.QueryInterface<org.freedesktop.PowerManagement.IInhibit>(); bool has; inhibit.HasInhibit (out has); Console.WriteLine ("HasInhibit:" + has); inhibit.Inhibit ("banshee", "playing music", out trash); inhibit.HasInhibit (out has); Console.WriteLine ("HasInhibit:" + has); But: * It didn't work (computer got suspended). * And, I got this printed on the console (like if the inhibit had no effect): HasInhibit:False HasInhibit:False So, any hints? Am I doing something wrong or this is the info we were looking for? Anyway, I'll try with openSUSE 11.1 soon.
(In reply to comment #5) > (In reply to comment #4) > > For me, if I'm listening to or watching something, experiencing the media takes > > a higher priority over battery conservation. > > I don't agree. I would prefer an interruption by the sleep mode than a total > interruption because the battery ran out. If this is not going to include a > visible-user-preference, I would only agree with a fix for this if it doesn't > affect the situation in which there's no AC connection. I cannot possibly imagine who would like to watch a video or listen to music and be forced to come back to the PC every x minutes to make sure the music keeps on playing. Andres, your scenario only makes sense if you are tied to your PC 24/7 and never listen to music while doing something else that does not involve the PC In my case, 50% of the time I am listening to music while doing other non-PC stuff since my computer is my stereo (as is the case with pretty much everyone I know, stand alone stereos are a thing of the past) the lack of this feature is preventing me from using Banshee as my default player... My wife and I use the PC and our toddler often interrupts so we need to keep the Power Management settings to make sure the PC is not on 24 hours needlessly but when we play music or watch videos we expect it to stay on. When we watch videos we switch video output to our big TV and are no longer close enough to the PC to "shake the mouse" every 15 minutes. I have to say I am surprised you don't see this functional requirement as a developer
(In reply to comment #13) > When we watch videos we switch video output to our big TV and are no longer > close enough to the PC to "shake the mouse" every 15 minutes. I have to say I > am surprised you don't see this functional requirement as a developer Of course am not opposed to avoiding this painful situation, but I was talking about the scenario in which you didn't plug the laptop to AC (which is not very frequent if you're at home, the only scenario that has been pointed out is when you're in a plane for instance; and anyway, banshee should prevent sleep in this case, but not hibernation in case of total battery consumption).
Has anybody taken this one forward? I think it's an important usability bug.
Any idea if this bug will be taken up for resolution? I had to give up on Banshee back in 2009 because of this and now that Banshee is part of the default Ubuntu package I am willing to try it again... however, this functionality bug makes it unusable for me By the way, how is the status "unconfirmed" it is a proven fact that Banshee does not inhibit suspend/hibernation activities...
I filed a bug in launchpad and was directed to this bug. https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/790704 "In order to save power, I have power management in Ubuntu set to turn off my monitors after 5 minutes of inactivity. Shouldn't watching a video in Banshee keep my machine active?" I feel that if media is being played, power management shouldn't get involved. After all, televisions and radios don't shut themselves off when you haven't touched the controls (maybe this could happen once the video stops etc). Also, I think most other media players keep the machine from idling. I just don't think most users would expect the machine to go to sleep while something is playing.
(In reply to comment #17) > I filed a bug in launchpad and was directed to this bug. > > https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/790704 > > "In order to save power, I have power management in Ubuntu set to turn off my > monitors after 5 minutes of inactivity. Shouldn't watching a video in Banshee > keep my machine active?" > > I feel that if media is being played, power management shouldn't get involved. > After all, televisions and radios don't shut themselves off when you haven't > touched the controls (maybe this could happen once the video stops etc). Also, > I think most other media players keep the machine from idling. I just don't > think most users would expect the machine to go to sleep while something is > playing. Yes, I agree - especially if on AC power. IMHO if running on battery power banshee should still inhibit sleep, but stop if battery levels become critical.
Created attachment 222584 [details] [review] This patch sets the Power Settings according to the current action of the player as suggested in the patch The patch uses the gnome-session daemon for controlling the screensaver and the suspend settings. The patch contains some lines from Monodevelop, I don't know how to get rid of them.
Created attachment 222590 [details] [review] After some more tests playing music I realised it didn't work at the end of the file, so here a reworked version, even better :). Same problems with MD Lines.
Thanks for the patch Samuel! We're now in feature freeze, so it's a bit late to get it into Banshee 2.6. Sorry I couldn't review it earlier. I'll try to get to it after the upcoming major release. Don't hesitate to ping me if I don't get to it.
+1 for a fix :-)
+1 - IMO this is really important, it is enough for someone who uses suspend to choose a different player. Regarding the behavior in different power situations, it might be useful to find out how other media players tackle the issue.
Created attachment 234670 [details] [review] Fixes the unecessary Commit Lines from MonoDevelop and some FileName Comments
Any chance we can get this committed?
(In reply to comment #25) > Any chance we can get this committed? Samuel, I appreciate your patches and dedication! That being said, it turns out we're facing big architectural changes ATM, so I think I'll review this patch past-2.9.0 if you don't mind? Feel free to ping me again after we release 2.9.0, if I don't remember to act on it.
Created attachment 281797 [details] [review] Fixed to apply to master
<thinkabout> knocte: so the freedesktop api doesn't allow to inhibit suspend: http://people.freedesktop.org/~hadess/idle-inhibition-spec/ch03.html <thinkabout> knocte: with new Gtk3 it should perhaps use GtkApplication.Inhibit See: https://developer.gnome.org/gtk3/stable/GtkApplication.html#gtk-application-inhibit
But, that's not bound in gtk-sharp yet. <thinkabout> Could anyone with an ubuntu install (more modern) check if the dbus-Path org.gnome.SessionManager is there. Should be on the Session Bus.
Created attachment 282336 [details] [review] Does only suspend, not fixing the Screensaver too.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.