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 688474 - Banshee 2.6.0 resets volume to 100% when skipping a track
Banshee 2.6.0 resets volume to 100% when skipping a track
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: Playback
2.6.0
Other Linux
: Normal normal
: ---
Assigned To: Banshee Maintainers
Banshee Maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2012-11-16 16:01 UTC by Florian Berger
Modified: 2020-03-17 09:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Florian Berger 2012-11-16 16:01:05 UTC
To reproduce:

1. Start some song in Banshee with volume at 100%.
2. Turn volume down.
3. Skip to the next song.


Expected behaviour:

The volume should stay at the level adjusted in the previous song.


Actual behaviour:

After a short delay, the volume ramps back to 100%. This is reflected by the volume icon.


This bug does not surface when a track ends naturally, only on manual skipping.


Environment:

Banshee 2.6.0, Gentoo Linux, kernel 3.0.4-ck, i686, Mono 2.10.2, GStreamer 0.10.35.

No sound servers or anything, pure ALSA.


This might be related to bug #647960.

Thanks for considering.
Comment 1 Andrés G. Aragoneses (IRC: knocte) 2012-12-02 23:23:41 UTC
This bug is kind of similar to bug 686908. That bug has a patch in there, do you mind testing that patch Florian?
Thanks
Comment 2 Gary Murphy 2013-01-08 22:41:38 UTC
in my case it is happening on every new track being played; I have no extentions active, no gapless play, I notice on the pavumeter that the Banshee process closes the connection to pulseaudio on every concluded track and when it reopens, not always, but most often it resets the volume to 100% -- this is with Banshee 2.6.0 under Ubuntu 12.10

Perhaps this is significant: the volume reset on each natural track change appears to be more reliable when in Fullscreen mode, in normal window mode it can last for several tracks before changing and it /could/ be that the shift back from a screensaver is involved -- this machine powers our in-house FM radio, so it is left running, and in previous editions would be left running in fullscreen so if someone heard a track and wanted information, they could poke into the server room and see the lovely (and unique to Banshee) fullscreen Now Playing display.

And this is also new behavour: Fullscreen mode no longer blocks the gnome-screensaver or xscreensaver; previous versions would stay with the Now Playing on Fullscreen, but the machine now times out and goes to screenlock.
Comment 3 Florian Berger 2013-05-11 19:15:30 UTC
Hi Andrés, I have tried the patches from bug #686908.

The patch labeled 'Alternative patch' does not fix the problem.

The patch labeled 'workaround for os x systems' has no effect either, but that might not be surprising since `ifdef __APPLE__` probably disables it on Linux.

I have removed the `ifdef...endif` to apply it in any case. No effect. Still every skip forward resets the volume to 100%.
Comment 4 André Klapper 2020-03-17 09:55:22 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.