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 592115 - Pausing audio on forced hibernate/suspend etc
Pausing audio on forced hibernate/suspend etc
Status: RESOLVED DUPLICATE of bug 638583
Product: banshee
Classification: Other
Component: Playback
1.4.3
Other Linux
: Normal enhancement
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-17 17:24 UTC by Ian Hutchinson
Modified: 2011-09-17 21:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ian Hutchinson 2009-08-17 17:24:33 UTC
I was listening to music on my laptop the other day, and I found myself away from a power outlet. With this, I just let my battery run down to the point where it forced hibernate to stop any mucky unclean shutdown problems. While doing this, I was listening with headphones with the volume at full. This is on my laptop with built in speakers.

Of course, I took the headphones out when the hibernate was complete and I put the laptop back into its bag. When I managed to get to a power outlet in Starbucks, the system was booting back up, that the music was playing full volume out of the internal speaks.

And of course, when a laptop is booting up, and when confronted with a password screen to return to the session, this isn't the most responsive time to quickly pause audio.

In the end, I grabbed the headphones to redirect the audio until I was able to manually pause the music. A Starbucks isn't really an appropriate place for this to happen, as you can tell.

I reckon Banshee should be able to detect when a hibernate is about to happen, and pause the audio so that it doesn't start again automatically when repowered. I'm sure that this is just a flaw on my part, but I'm sure there are a few other people who have found themselves in this situation. Also when users are switched and when suspends are done, as many are done in a flash decision.

It would be a welcome modification to stop this kind of hiccup happening again.
Comment 1 Andrés G. Aragoneses (IRC: knocte) 2009-08-17 18:15:19 UTC
+1, indeed a very annoying bug (or very cool feature ;)
Comment 2 Michael Martin-Smucker 2011-09-17 21:05:08 UTC
I realize that this bug was reported first, but I'm marking it as a duplicate of Bug 638583, which has a lot more discussion and even a patch.

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