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 638583 - Pause playback on suspend/hibernate, and resume playback with long fade-in on resume
Pause playback on suspend/hibernate, and resume playback with long fade-in on...
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: general
git master
Other Linux
: Normal normal
: 1.x
Assigned To: Alex Launi
Banshee Maintainers
gnome[unmaintained]
: 592115 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-01-03 16:49 UTC by Alex Launi
Modified: 2020-03-17 08:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add UPower backend (31.25 KB, patch)
2011-01-14 14:40 UTC, Alex Launi
none Details | Review
Fix some leftover junk. (31.25 KB, patch)
2011-01-14 14:52 UTC, Alex Launi
needs-work Details | Review
power management patch (28.96 KB, patch)
2011-04-18 15:23 UTC, olivier dufour
none Details | Review

Description Alex Launi 2011-01-03 16:49:57 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.
Comment 1 David Nielsen 2011-01-03 17:52:15 UTC
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?
Comment 2 Alex Launi 2011-01-03 20:23:10 UTC
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.
Comment 3 David Nielsen 2011-01-03 20:25:38 UTC
Oh I don't disagree, of the two existing options I suggest pausing, crashing is so.. 2000
Comment 4 Andrés G. Aragoneses (IRC: knocte) 2011-01-07 22:25:14 UTC
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 :)
Comment 5 Andrés G. Aragoneses (IRC: knocte) 2011-01-08 18:43:51 UTC
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.
Comment 6 Alex Launi 2011-01-08 19:48:57 UTC
Andés, that's a very elegant, and considerate solution.
Comment 7 Andrés G. Aragoneses (IRC: knocte) 2011-01-08 20:32:21 UTC
Glad you liked it.
Comment 8 Alex Launi 2011-01-14 14:40:28 UTC
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.
Comment 9 Alex Launi 2011-01-14 14:52:05 UTC
Created attachment 178327 [details] [review]
Fix some leftover junk.

Removes some leftover junk from the previous patch.
Comment 10 Alex Launi 2011-02-20 18:13:36 UTC
For the record, iTunes pauses on suspend and does not unpause on resume. I find it much less stressful.
Comment 11 Gabriel Burt 2011-02-26 19:32:13 UTC
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?
Comment 12 olivier dufour 2011-04-18 15:23:06 UTC
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.
Comment 13 Michael Martin-Smucker 2011-09-17 21:05:08 UTC
*** Bug 592115 has been marked as a duplicate of this bug. ***
Comment 14 André Klapper 2020-03-17 08:55:55 UTC
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.