Version: 3.5 (using KDE 4.3.1) OS: Linux Installed from: Fedora RPMs If you set the session to not confirm logout, the volumes of kmix are forgotten when a reboot is done.
Interesting observation. Thanks, I will try that.
Just to clarify this: If you logout (without confirmation), volumes are remembered. It is specically if you reboot that volumes are forgotten. kdebase-4.4.2-1.fc12.x86_64
Ah, thanks for the additional input. This could explain a lot of other bug reports as well (not remembering master, not remembering certain preferences). This is clearly importannt. I hope to look into it soon - at least in May 2010.
I tested it and unfortunately can not reproduce it in either case (with/without confirmation). I tested it by adding debugging output. Next idea would be to build a non-debugging version. Probably an optimizer thing, or issues with KUniqueApplication.
SVN commit 1128454 by esken: More debug output for saving config. Required independent of bug 210262. CCBUGS: 210262 M +11 -0 kmix.cpp M +2 -0 mixer_alsa9.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1128454
*** Bug 213721 has been marked as a duplicate of this bug. ***
*** Bug 220655 has been marked as a duplicate of this bug. ***
Idea from Bug 220655: Test with "Change input source"
I have tested several variations like. - Machine under high load - Machine idle - Logout from K-Menu - Logout from Desktop context menu - Logout with or without confirmation I cannot reproduce the behaviour. If it still happens, it is likely out of the scope of KMix (e.g. a shutdown process that kills of KMix if shoutdown is too slow). Could you please check again with a recent KDE version?
.
Hi there, I managed to find a solution... Open Kmix configuration and UNCHECK restore volume option. Someone put inverse logic on that button... OR alsa/pulseaudio handles volume restore much better than kmix Check this bug on redhat bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=657373
Thanks for the link to https://bugzilla.redhat.com/show_bug.cgi?id=657373 . It is another hint that KMix volume restoration conflicts with Pulseaudio volume restoration. I'll probably merge this bug report with others if appropriate.
I think this might be the same issue as the one from bug 249180. I will not directly merge both bugs, but assign it over to the Pulseaudio backend maintainer, so he can either merge them, not merge them or give them back to me.
Yeah I think this is ultimately a dupe. The issue was that kmixctl (a command line app) didn't recognise PulseAudio as running and thus "restored" volumes (normally if PulseAudio is detected, it should refuse to restore volumes - just like if the tick boxes were always turned off) Sadly, the volumes were *saved* from kmix (the GUI app) which DID detect PA properly and thus didn't ever save anything. Thus kmixctl would always restore null or default volumes which have no relation to the previous volume. This should now be fixed in kmix 4.8.3 *** This bug has been marked as a duplicate of bug 249180 ***