Rhythmbox/Banshee will not minimize to sound-indicator if music is not playing

Bug #658590 reported by jhfhlkjlj on 2010-10-11
This bug affects 12 people
Affects Status Importance Assigned to Milestone
rhythmbox (Ubuntu)

Bug Description

Binary package hint: rhythmbox

I'm unsure if this is intended behavior but if I were to close Rhythmbox while music is paused or not playing the program will close.

See the vid. The expected behavior is for Rhythmbox to behave as it always has: Sitting comfortably in the tray/indicator. As a workaround I can play music, close/minimize it, then pause the music.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: rhythmbox 0.13.1-0ubuntu5
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic
Uname: Linux 2.6.35-22-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Mon Oct 11 14:06:01 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
SourcePackage: rhythmbox

description: updated
description: updated
belscb (thebelschners) wrote :

Likewise; I have the exact same problem.

Changed in rhythmbox (Ubuntu):
status: New → Confirmed
Mika Wahlroos (mpw) wrote :

This is apparently intentional. See bug #526552 about compliance with the sound menu specification. The specification itself ( https://wiki.ubuntu.com/SoundMenu#Music%20player%20section ) says:

"A compliant player should also keep playing if you close its window while it is playing; exit if you close its window while it is not playing; and remember exact state across sessions, so that after exit and relaunch it is as if the player had never exited."

The big problem is that the specification only really makes sense if the third part (exact preservation of state) also works, and Rhythmbox doesn't do that. That makes the behaviour of "close" rather inconsistent: if you invoke close while playing, the player will be hidden and can be restored with the same state if you restore it from the sound menu, but if you invoke close while not playing, state will be lost.

I think this is a major inconvenience. Think of the following scenario:

1. I have music playing in Rhythmbox and the Rhythmbox window is visible. Say, I have a particular artist selected in the Rhythmbox browser and am playing on shuffle, essentially meaning that I'm playing random tracks from that artist. This means the UI state is also important, not just the playback state.
2. I get a link to a YouTube video with music (or whatever) and decide to watch it, so I pause the music in Rhythmbox and hit Ctrl+W to get Rhythmbox out of my way in order to watch the video. Rhythmbox quits instead of hiding.
3. After watching the video I want to resume playback where I left off. The state is lost (including the track I was playing *and* UI state, e.g. having the artist selected in the Rhythmbox browser).

This breaks the user's flow in some cases pretty seriously, partially because state is lost and in particular because the loss or preservation of state is inconsistent.

I suggest that either Rhythmbox in Maverick should be modified to support exact preservation of state (including UI state) across sessions pretty quickly, or the change of making Rhythmbox quit on close should be reverted until exact preservation of state can be made to work.

Oh, god, I knew this would be intentional.

How about we close our chat client when we're not chatting with someone?

Changed in rhythmbox (Ubuntu):
importance: Undecided → Low
summary: - [10.10] Rhythmbox will not minimize to sound-indicator if music is not
- playing
+ Rhythmbox will not minimize to sound-indicator if music is not playing

Mika Wahlroos Rhythmbox doesn`t quit if it`s not playing if you make the status icon to own the main window but the icon appears in the notification area applet . So i think it`s not intentional it`s maybe they didn`t care having "two music player icons" in the panel or they never thought hiding rhythmbox is important. A fix could be to modify the status icon plugin in such a way that the status icon can own the main window and be hidden , but this will brake the option for the mouse weal to change song because you can`t change from the sound icon , so that could also go.

Mika Wahlroos (mpw) wrote :


I already have the status icon set to own the main window, so that doesn't appear to work for me as a workaround.

To me, both the bug and specification to which I linked appear to pretty clearly indicate that the behaviour of quitting when not playing is an intentional change. I simply argue that the change is not a good one until the rest of the specification (namely, preservation of state) is also fully working.

ValentinV (valentinverde) wrote :

Mika i`m sorry ... i`m using dockbarx and with it if i don`t have the rhythmbox icon in the sys tray it wont hide. i just tested with the window list applet and with that it hides to the sound indicator , but only when playing . But the window list is ugly and default i want to customize my machine as I want it and it seems things get harder with each release .

I would like to contest the sanity of this behavior. What about those that have extremely large libraries that are set to be scanned upon RB's startup?

Every time I want to navigate my player my computer has to rescan hard drives of music.

Dan Quade (danquade) wrote :

So how do we disable this retarded behavior?

Sebastien Bacher (seb128) wrote :

The behaviour is the one specified in https://wiki.ubuntu.com/SoundMenu#compliance, not a bug

Changed in rhythmbox (Ubuntu):
status: Confirmed → Invalid
Dan Quade (danquade) wrote :

Then change the specification. It is absurd and needs fixing.

Changed in rhythmbox (Ubuntu):
status: Invalid → Confirmed
Victor Zamanian (victorz) wrote :

I agree with unimatrix, it is an absurd spec. because it is very impractical. Can we file bugs against specifications? If this bug is strictly invalid, then I feel that that is what must be done.

Mika Wahlroos (mpw) wrote :


I'd like to point out that, as I said in comment #3, even if we sidestep the question regarding the sanity of the specification itself, it's definitely a bug that the Rhythmbox package in Ubuntu currently implements the specification only partially, leading to inconsistent behaviour. The package does implement the part about exiting if the window is closed while not playing, but does not implement the part about maintaining state across sessions. I'm inclined to believe that the latter part was added to the specification exactly because it would otherwise severely disrupt the consistency of behaviour and the user's flow. See comment #3 for a real-world scenario; I can give more if you're not convinced.

I argue that, as far as any single application goes, the specification should only be implemented either fully or not at all. This particularly applies to a high-prevalence application such as Rhythmbox. If you consider this particular one not to be a bug, should we instead open a new one for the Rhythmbox in Ubuntu not implementing the specification fully?

In relation to that, what's your understanding of how this inconsistency is going to be solved in the future? Is it just going to go away by itself in a future transition to Gnome 3? Or is the specification going to be fully implemented by Rhythmbox in Natty, thus perhaps making the behaviour consistent? Is that a realistic goal, seeing that Rhythmbox itself does little or nothing to implement full preservation of state?

Vish (vish) wrote :

@all :
Sebastien is not the person incharge of writing those specs, so, addressing your frustration towards him or on this bug report might not help getting this bug fixed.
To fix this bug the specs need to be changed. -> To change the specs, the best way is to bring up the discussion on the Ayatana mailing list. (Thats where the designers incharge of the specs are subscribed and can respond.)

Banshee is now following this behavior in natty. Updating the bug.

I will comment on Ayatana.

summary: - Rhythmbox will not minimize to sound-indicator if music is not playing
+ Rhythmbox/Banshee will not minimize to sound-indicator if music is not
+ playing
Sebastien Bacher (seb128) wrote :

stop reopening this bug that's not one, feel free to comment the design on the design list though

Changed in rhythmbox (Ubuntu):
status: Confirmed → Invalid

Shouldn't it at least be set to 'opinion'?

Sebastien Bacher (seb128) wrote :

if that can stop comments at the wrong place sure let's try!

Changed in rhythmbox (Ubuntu):
status: Invalid → Opinion
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers