GNOME Bugzilla – Bug 686908
Banshee doesn't remember volume setting
Last modified: 2014-07-22 09:58:36 UTC
Originally reported at: https://bugs.launchpad.net/bugs/1071277 If I set the music volume using the volume control in the top right of Banshee, then quit and restart the program, the volume is reset to 100%. ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: banshee 2.6.0-1ubuntu2 ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7 Uname: Linux 3.5.0-18-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.6.1-0ubuntu6 Architecture: amd64 Date: Thu Oct 25 12:25:15 2012 InstallationDate: Installed on 2012-04-24 (183 days ago) InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120328) MarkForUpload: True SourcePackage: banshee UpgradeStatus: Upgraded to quantal on 2012-09-17 (37 days ago)
Hello, I have exactly the same problem on OpenSUSE 12.2. Dépot: GNOME:Apps 12.2 Nom: banshee Version: 2.6.0-42.5 Arch: x86_64 Fabricant: obs://build.opensuse.org/GNOME
Just to confirm that this happens on Gentoo too: System: x64,testing (~amd64) Package: media-sound/banshee-2.6.0
Same problem on archlinux. the volume button(top right) is set to 100% every time banshee start. when I play the first track, the system volume up to 1.0, even if the banshee volume has baeen changed. arch: x86_64 version: banshee 2.6.0-2 removing this commit (http://git.gnome.org/browse/banshee/commit/?id=96ee436bbf95bad7565e494555695f797f0382d0) solved the problem, but the volume button is set to 0%.
Hey Timo, a user bisected this problem to a commit of yours, any idea? :)
Might be related to commit: http://git.gnome.org/browse/banshee/commit/?id=9d6789e2ba5c8ef4b3145cbd92d0db5470ce3fbe Maybe it'll help to remove the plattform check and do this on all plattforms?
Created attachment 229920 [details] [review] workaround for os x systems Only explicitly call the callback on OS X systems, which is not called upon pipeline setup (see https://bugzilla.gnome.org/show_bug.cgi?id=680917).
Chow, beguam, corec, keskispace: do any of you guys mind trying the patch that Timo posted? It would be appreciated. Thanks in advance.
I've applied the patch and the volume is not anymore reset to 100%, but .. I've noticed with this patch the volume is set to 0% at start up, and sets to system's volume when the first track is playing. (it's the behaviour that I had with version 2.4).
Weirdly enough I can't reproduce the bug even without the patch applied. Banshee automagically remembers its last volume. It could be a side effect of Pulseaudio and the session volume saving thing though.
Does ALSA (without pulseaudio) actually saves the volume of a client (like banshee) anywhere? I know that PA does, but I am not sure about ALSA (where would it store it?). On OS X there is also no volume storage, or at least gstreamer playbin2 does not store the volume of a setup pipeline back to disk anywhere. Thats why on OS X the volume resets each time banshee is restarted. If alsa also does not store the volume, we might think of storing the last set volume when banshee exits, so we can restore it upon next start. This would at least for all platforms, no matter what the backend sound engine is used.
I am experiencing an issue that is either identical or very similar to this one and I just thought I might add my two cents about it. Banshee 2.6.0-5 from Debian Experimental, using GStreamer 1.0, with Pulseaudio 2.1-2, boosts the system volume to 100% when starting playback. The volume can be turned down and remains lowered while Banshee is running, even if playback is restarted. The volume gets boosted to 100% again if the application is restarted, or if the system volume is muted then unmuted again. Muting Banshee from Sound Settings and unmuting it does not reset the volume. Banshee 2.6.0-2linuxmint1 from Linux Mint 14 (based on Ubuntu 12.10), using GStreamer 0.10, with Pulseaudio 1:2.1-0ubuntu4 installed does not exhibit this issue. Installing Banshee 2.6.0-2linuxmint1 from Linux Mint 14 in Debian exhibits the same issue as Debian's version, while installing 2.6.0-5 from Debian Experimental in Linux Mint 14 does not exhibit the issue at all, suggesting the problem does not lie directly with Banshee, but with one of its dependencies.
AFAIU Banshee cannot be compatible with GStreamer 1.0, unless downstream has applied custom patches (there's a bug open with one). Alex, do you mind testing Timo's patch?
Debian's build in Experimental is definitely using GStreamer 1.0. From the console output: karashata@Kara01 ~ $ banshee [Info 18:40:44.296] Running Banshee 2.6.0: [Debian GNU/Linux 7.0 (wheezy) (linux-gnu, x86_64) @ 2013-01-03 01:51:00 MYT] [Info 18:40:46.332] Updating web proxy from GConf [Info 18:40:46.384] All services are started 1.642221 [Info 18:40:48.923] nereid Client Started [Info 18:40:48.999] GStreamer version 1.0.4.0, gapless: True, replaygain: False I'll see about testing the patch as soon as I can and report back.
(In reply to comment #12) > AFAIU Banshee cannot be compatible with GStreamer 1.0, unless downstream has > applied custom patches (there's a bug open with one). Yeah, I've applied the patches in Debian, since we're going ahead with the Gstreamer 1.0 porting archive-wide now. If you've seen the bug with the patches, just commit them already.
Unfortunately I don't seem to be able to test the patch. It seems the GCC compiler installed on my system isn't working right now. I'll have to get that fixed before I'll be able to do anything further. I also need to find Debian's source code for version 2.6.0-5, the code I got from Debian's git repo ended up being version 2.4.1, which doesn't experience this issue. (Of course, unless I can get the GCC compiler working, getting the source code won't be much use...)
I applied this patch to the latest git master and I see similar behavior as keskispace. The volume is set to 0 when Banshee starts but once a track begins playing the volume is set to what appears to be the previously set volume. This is slightly different from keski as I don't think it is going to the system volume but rather the previously set volume. Maybe we are already saving the previous volume and can just set it on startup? I'll have to dig into the code to find out. I am running Ubuntu 12.04 with gsteamer 0.10.36.0.
*** Bug 694813 has been marked as a duplicate of this bug. ***
I'd definetely vouch to merge the patch I attached in comment #5. This baiscally revokes the changes, that introduced the bug by my commit here: https://git.gnome.org/browse/banshee/commit/?id=96ee436bbf95bad7565e494555695f797f0382d0 By revoking the changes for Linux, we go back to pre-2.6 behaviour, which had only trouble displaying the volume (before playback was started) but at least the volume level did not jump around while playback. I understand that jumping volume is very annoying when listening to music, and I'd rather have an inaccurate volume display than jumping volume levels. Lots of users are complaining on the mailing list and bugtracker, too.
*** Bug 696717 has been marked as a duplicate of this bug. ***
Created attachment 239997 [details] [review] Alternative patch (In reply to comment #19) > I'd definetely vouch to merge the patch I attached in comment #5 I guess you mean comment#6 ? Thing is, if we commit that, we may get the other buggy behaviour which Phil&keskispace explain. (In reply to comment #5) > Might be related to commit: > http://git.gnome.org/browse/banshee/commit/?id=9d6789e2ba5c8ef4b3145cbd92d0db5470ce3fbe How can that be related if that is a commit that only changes behaviour only in OSX? > Maybe it'll help to remove the plattform check and do this on all plattforms? Good point, I'm posting here a patch that does exactly that, can people test please?
The patch by knocte did not work at least for me. Behavior did not change at all, and the volume still gets maximized at startup.
On a linux system with pulseaudio-3.0 the patch at comment #21 has no effect. The patch at comment #6 fixes the problem for me.
*** Bug 613726 has been marked as a duplicate of this bug. ***
*** Bug 700367 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > The patch at comment #6 fixes the problem for me. Thanks for the info Chris! Could you also tell us if this patch makes you experience the issue that Phil explains at comment#16? (In reply to comment #25) > *** Bug 700367 has been marked as a duplicate of this bug. *** Nick Brow, can you also test patch in comment#6 please?
Unfortunately I cannot test it. My glib is older than what is required to build from scratch. My Fedora 18 is from the stable branch.
(In reply to comment #21) > Created an attachment (id=239997) [details] [review] > Alternative patch > > (In reply to comment #19) > > I'd definetely vouch to merge the patch I attached in comment #5 > > I guess you mean comment#6 ? > Thing is, if we commit that, we may get the other buggy behaviour which > Phil&keskispace explain. > In my case, I reproduce same behaviour as Phil. Even though I'm hesitant of having different behaviours on Mac, I guess committing Timo's patch is the lesser of two evils. This is going to go to the stable-2.6 branch and master, which means it will be present in 2.9.0, and 2.6.2 if we make such a release. Its presence in 2.9.0 won't matter much, though, as we're planning to use GStreamerSharp backend by default in 2.9.1 (instead of libbanshee). So I'm closing this bug after I did this two commits: https://git.gnome.org/browse/banshee/commit/?id=d8ae526714a18a773af4bf5e5d6b10cdc5644ec1 https://git.gnome.org/browse/banshee/commit/?h=stable-2.6&id=7797658ca8096c15d578d8e3f77241ed1516795a Sorry for the wait, thanks for the patience.
*** Bug 707257 has been marked as a duplicate of this bug. ***
I found a better way around this bug. I just edited my .asoundrc to look like this: pcm.!default { type plug slave.pcm "softvol" } pcm.softvol { type softvol slave { pcm "hw:2,0" } control { name "Master" card 2 } } This creates a virtual "Master" volume slider for my external USB sound card (hw:2,0) - I can use this to lower the volume even if Banshee decides to push it up to 100%. Banshee doesn't use this Master volume slider which is odd, but I can control it myself using any mixer gui I want.
*** Bug 731361 has been marked as a duplicate of this bug. ***