Rhythmbox does this deliberately so that the playback controls are available immediately.  Also, you're not getting the proper playback controls due to this: http://git.gnome.org/browse/rhythmbox/commit/?id=e0e5d06e3e3d2651639c0d0579635c3aa126dd4f

I found it weird first too, but that's actually useful because it allows you to go directly to RB and choose another album if you like.

With the newest Rhythmbox code, I'm getting all three playback controls, but still no text for the title or description.

Would it be possible for the notification to have the name and description of the first track instead? That way the user would know what will be played when the play button is pressed. It's probably more elegant then saying "Rhythmbox", which I believe what the earlier code was putting as a title in that notification.

That's probably possible.  I'd be a bit concerned that users might expect the track to start playing with no further action, which might trigger 'why is there no sound' troubleshooting or 'I'm in a library and my headphones aren't plugged in' panic.

Showing the notification when I just start RB is a bit weird. Wondering if we need the thing in the MT at all before we actually play something...

OTOH, it would feel a little inconsistent not to have the notification in the messaging bar if you've not played anything, but have it when you have. If you keep RB open for hours (or days with suspend), you don't even remember you already played something, and yet this affects RB's behavior.

Isn't there a way to add the persistent notification without showing it? E.g., the Shell could just special-case empty notifications, which anyway makes much sense.

There are two parts here:

1) A new notification being shown. This should not happen - we should find a way to suppress it.

We should not be showing a notification from an application that has an active window by checking it in processNotification() in notificationDaemon.js .
However, right now, both tracker.focus_app and this.app are null for me. tracker.focus_app is null because the notification is sent before the window is shown - I can see it getting set later in _onFocusAppChanged() . this.app is probably null for the same reason, because the way we are trying to figure it out is by calling
Shell.WindowTracker.get_default().get_app_from_pid(this._pid);
which probably returns null because the window is not yet created. So it seems that this can be fixed if Rhythmbox were to send the first notification after a window is shown.

2) A summary notification being placed in the message tray. We previously decided that it should be there to provide the user with a consistent experience with the Rhythmbox's resident notification. Right now it looks like this:

[o]
                           |<< |> >>|

I propose that we make it look like that, where Americano is the song that will play if you press Play:

[o] Americano
    by Lady Gaga from Born This Way
                           |<< |> >>|

I think practically speaking we can just make the thing resident after the first notification.

Initial startup is a bit strange anyway - it is really the only time RB is "stopped" other times it is paused.

Jonathan, do you think you could make a patch for Rhythmbox to not place a resident notification in the message tray when it starts, but rather wait till the first track is played?

I still think this behavior would be wrong. Why not make the Shell detect empty resident notifications, and silently add them to the message bar, without showing them first?

The resident notification can't be empty because the user needs to be able to interact with it in the message tray. If Rhythmbox were to send the notification after the window is shown, we would not be displaying it and would silently place it in the message tray. However, it needs to be pre-filled with the information about the song that would get played if you pressed Play. Basically, this is what I proposed in Comment 7.

I agree with Jon that adding the resident notification after the first track gets played is good enough. Either behavior is fine with me.

I removed the notification on startup in commit 64d77ff.  Creating a notification with the details of the first track that would be played isn't really feasible at the moment.  It may be later.

OK then.