GNOME Bugzilla – Bug 638583
Pause playback on suspend/hibernate, and resume playback with long fade-in on resume
Last modified: 2020-03-17 08:55:55 UTC
When Banshee is playing and the computer goes into suspend, the music stops (obviously), but when resumed the playback starts immediately. This is really annoying. Often I'll suspend, take my laptop to the coffee shop to get a change of scenery, and then as soon as I open it up something will start blasting from the speakers bothering everyone else. Sure I could be more diligent in pausing before suspending, but I don't think there's any good use case for the current behavior.
Well the stated objective of resuming from suspend is to return to what you were doing, which included listening to music. I would say this is entirely intentional, though there may be a point in pausing playback on resume. However this sounds like an environment or distribution policy issue. How does e.g. Rhythmbox or Totem handle this?
Stated objective where? I think that's a gross oversimplification. For instance, I usually suspend at night when I go to bed only because it is faster than a cold boot. I'm starting a new day and although I may work on some of the same things I'm not really continuing where I left off. Totem crashed on resume. RB does not pause. As for this being a distribution policy issue, I disagree. Perhaps it is the kind of thing that should end up in a gsettings/gconf key that distros can change, but we should strive for the best default experience. I think the main question to ask is, what is the /advantage/ of resuming playback on resume. Typically suspend is not used for just walking away from the computer. For instance I could see pausing playback when the screen is locked, and then resuming when unlocked (not suggesting we do this- let's not get derailed into a discussion of this), but suspend/resume are for longer term away periods. Listening to music is not the same as working on a document. The idea of "returning to what you were doing" does not really apply. Listening to music was probably not your primary activity, probably you were listening to music while doing something else.
Oh I don't disagree, of the two existing options I suggest pausing, crashing is so.. 2000
The only (rare) use case I would see for the current behaviour is: using Banshee as an alarm clock ;) That is, you leave it playing music... and hibernate the computer. Then you configure the BIOS to start the computer at a certain time :)
An approach that would cover the use case above would be to not pause, but fade in from silence to the X percentage of volume that banshee had before hibernation, for a duration of about a minute. This way the playback keeps going, but it doesn't annoy you at the first place after hibernation, so you can notice the music is on and have enough time to stop it if you want to.
Andés, that's a very elegant, and considerate solution.
Glad you liked it.
Created attachment 178324 [details] [review] Add UPower backend Add's a backendable Banshee.Power service, and a UPower reference implementation. It exposes information about on-battery, low-battery, and suspending/resuming signals. This is patch 1 of a set to add fade in on resume. This seemed like the best approach as the other information can be useful to other plugins. For instance, we could stop scanning bpm, or similarity when on low-battery.
Created attachment 178327 [details] [review] Fix some leftover junk. Removes some leftover junk from the previous patch.
For the record, iTunes pauses on suspend and does not unpause on resume. I find it much less stressful.
Comment on attachment 178327 [details] [review] Fix some leftover junk. Looks really good, Alex! What is the idea of how to use the Lid properties? Banshee.sln 268 {3C377337-8E6B-4327-860B-A43197B145C0}.Release|x86.ActiveCfg = Release|Any CPU 269 {3C377337-8E6B-4327-860B-A43197B145C0}.Release|x86.Build.0 = Release|Any CPU 270 {3C377337-8E6B-4327-860B-A43197B145C0}.Windows|Any CPU.ActiveCfg = Debug|Any CPU Shouldn't build it on Windows data/addin-xml-strings.cs 30 31 // ../src/Backends/Banshee.UPower/Banshee.UPower.addin.xml 32 Catalog.GetString (@"UPower power backend for delivering on-battery, suspend, and resume information."); you can prevent this from getting added by adding UPower to the blacklist in build/AddinXmlStringExtractor.cs src/Backends/Banshee.UPower/Banshee.Power.UPower/PowerManager.cs 5 // Alex Launi <alex.launi@canonical.com> 6 // 7 // Copyright 2011 Alex Launi Just to confirm, it's not copyright Canonical? src/Backends/Banshee.UPower/UPower/Client.cs 72 public bool LidIsClosed { 73 get { 74 return Get ("LidIsClosed"); can put these getters on one line, ala `get { return Get ("LidIsClosed"); }` src/Backends/Banshee.UPower/UPower/Proxies.cs 24 // OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 25 // THE SOFTWARE. 26 using System; newline above using System; src/Core/Banshee.Services/Banshee.MediaEngine/PlayerEngine.cs 51 private PlayerState last_state = PlayerState.NotReady; 52 53 private ushort saved_volume; looks like stuff from the suspend/resume-volume patch got left in? src/Core/Banshee.Services/Banshee.Power/IPowerManager.cs 34 bool LidClosed { get; } 35 bool OnBattery { get; } 36 bool OnLowBattery { get; } OnLowBattery isn't clear to me; is it 'IsBatteryLow', basically?
Created attachment 186206 [details] [review] power management patch Heya, I see that the patch have no new fix from Alex because he is busy. So here is a new patch which just fix feedback and build with last git. I am on holiday at home to look after my children, so I have free time. For question about what mean OnLowBattery: Here is a quote from documentation: "Indicates whether the system is running on battery power and if the battery is critically low. This property is provided for convenience." So it indicate when battery is near finished and need to plug in your computer.
*** Bug 592115 has been marked as a duplicate of this bug. ***
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.