org.mpris.MediaPlayer2.MediaHub player is exposed at startup, making the indicator show a player that it's not fully functional

After having a discussion with the indicator team, the proposal is to make sure that media-hub exports a generic default string for the case when there is no current player. This happens directly after a fresh bootup. In this case, indicator-sound can simply hide itself until a player is loaded.

Also, once the functionality that sets the current player is changed from a UI focus-based approach to a last-played approach, media-hub will more accurately export the correct current player over MPRIS to indicator-sound. This is a separate bug: https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1538703

Seems if there is no previously active player we shouldn't show anything or is thatthe intent

To clarify, “indicator-sound can simply hide itself” should be “indicator-sound can simply omit the playback section of the menu”. The rest of the menu should still be present.

I doubt that’s a good solution, though, for two reasons. First, if a system component pretends to be an app, that pseudo-app will keep appearing confusingly in places we don’t expect: trust prompts, storage consumption UI, network activity UI, etc. Needing to hide it in every place it might appear is just asking for bugs.

Second, it would mean there are no playback controls in many cases where people would expect them.

The player should be whichever app the user sees as being responsible for the playback. So in the case of Media Hub, the player is whichever app sent the stream to Media Hub.

Here’s a perfectly reasonable but probably-difficult-to-implement test case:
1. Send a message to a Gmail address, containing a link to a YouTube music video.
2. In the Gmail app, open the message.
3. Start playing the video.
4. Switch to another app.
5. Open the sound menu.

What you should see: “Gmail” with playback controls.

What you currently see: “Media Player” with no playback controls.

Yes thanks for that clarification as I did mean to say the control portion of indicator-sound, not the entire indicator itself.

Can you cite an example where a system component might act as an app? I want to make sure that this isn't only a hypothetical situation. Also, I'm not sure how the second part of your 2nd paragraph is relevant for this bug. That seems like one or more separate bugs to solve if a system component is showing up undesirably in those other situations.

The example scenario that you give isn't a good one to demonstrate the current bug only because Oxide and media-hub integration aren't fully implemented and usually requires special handling when compared to the average application. The main case that's not currently clear in my mind is what do we want to display in indicator-sound on a fresh boot of the phone. If the controls are not hidden, then what should it look like and how should it behave?

A second thing to solve will be the case when all media applications have been closed by the user essentially getting back to the first boot state. All media-hub sessions have been closed so any track metadata and the playlist associated with that session have been lost. So we can't simply keep allowing the MPRIS controls to control the last media-hub session because it's no longer valid. So do we hide the controls? If not, what else can we do?

No progress move to backlog

oops stomped on johns change