Make PlayerControlView work as a standalone component

[fourofspades]

Porting my app from ExoPlayer to Media3, and have struggled around most of the gaps in the information, and finally have something that works.

I'm down to my last issue to fix, specifically that the next/previous track buttons aren't showing in PlayerControlView. They are showing everywhere else:

• The notification has them, and they work.
• Android Auto works.
• Next/Previous on my car's hardware buttons work.

Given all this, I think would usually assume the player is being build correctly, and it's something else, however, I briefly see the next/prev controls, when the activity loads, until the the player gets connected, then they disappear.,

I did a bit of debugging, and calling hasNextMediaItem() returns true, as does hasPreviousMediaItem() when I ask my mediacontroller if it's got things to play in the list.

I have tried all the usual things like forcing it to show using setShowPreviousButton(true); and setShowNextButton(true); and also setting this in the XML, this also didn't work.

I have tried stripping my player back to the basics, with none of the fancy stuff, still no joy. I'm not doing anything fancy, just a list of MediaItem of audio streams.

I'm now thinking about going back to Exoplayer, and parking Media3, as i've run out of ideas. Hoping someone here might have some ideas on what to look at next.

[fourofspades]

I don't believe it's related to #511

For the following reasons:

1. The Next/Previous buttons appear briefly then disapper when the player knows what's playing.
2. I have downgraded material libs to 1.2 and it still does it.
3. I have tried putting the control elsewhere.

[tonihei]

Porting my app from ExoPlayer to Media3, and have struggled around most of the gaps in the information, and finally have something that works.

Sorry to hear that you couldn't find all the information you needed. Would you mind listing some of the topics that were hard to find help for? We'd really like to improve documentation where needed.

The Next/Previous buttons appear briefly then disappear when the player knows what's playing.

Based on your description, it sounds like something in the media structure or available commands is changing that causes this problem. After the buttons disappear again, can you log the value of player.isCommandAvailable(COMMAND_SEEK_TO_NEXT)?

And for more context:

• Are you playing a live stream or regular media in a playlist?
• Are you connecting the View to a MediaController or directly to ExoPlayer?
• Are you using PlayerView directly or PlayerControlView as a stand-alone class? PlayerControlView isn't really meant to be used on its own. One thing that could happen is that PlayerControlView has a "minimal" mode that shows fewer buttons to save space. This should only activate if the entire PlayerView gets very small, but if you use it as a stand-alone UI element, it may trigger this mode as well.

I'm now thinking about going back to Exoplayer, and parking Media3, as i've run out of ideas.

That shouldn't make a difference because the code for this UI module is exactly the same. The only catch is that we renamed Player(Control)View -> LegacyPlayer(Control)View and StyledPlayer(Control)View -> Player(Control)View. I wonder if there are behavior differences because you effectively changed the View class? When you use the migration script, it will automatically migrate the class names too, but this wouldn't work if you updated the package names manually.

[fourofspades]

mediaController.isCommandAvailable( COMMAND_SEEK_TO_PREVIOUS_MEDIA_ITEM ); = false
mediaController.isCommandAvailable( COMMAND_SEEK_TO_NEXT_MEDIA_ITEM ); = false

I have a list of live steams loaded.
I'm connecting the PlayerControlView via a MediaController.
I'm using PlayerControlView as a standalone class.

Having read your post, I have changed my code to use PlayerView, and i'm seeing the next/previous controls. I guess that gives me something to start looking into.

As for documentation, I will go back and make a list of specifics, one of the key items is the lack of Java documentation, where the new Kotlin language is very dominant.

[tonihei]

mediaController.isCommandAvailable( COMMAND_SEEK_TO_PREVIOUS_MEDIA_ITEM ); = false
mediaController.isCommandAvailable( COMMAND_SEEK_TO_NEXT_MEDIA_ITEM ); = false

What are values of COMMAND_SEEK_TO_NEXT and COMMAND_SEEK_TO_PREVIOUS? Note that they have a slightly different meaning and especially for live streams only these ones may be true (which should still be sufficient to show the button).

Having read your post, I have changed my code to use PlayerView, and i'm seeing the next/previous controls. I guess that gives me something to start looking into.

That's actually a relatively strong signal that you may have seen the "minimal mode" I was mentioning. If you want to know for certain, you could check with a debugger what the value of playerControlView.controlViewLayoutManager.isMinimalMode is.

[fourofspades]

Many Thanks, Confirmed, playerControlView.controlViewLayoutManager.isMinimalMode is true.

What's odd, there is plenty of layout space for the controls. Is there a suggestion on how to fix this? I can't see anything in the PlayerControlView to set if minimal mode is used.

[tonihei]

@icbaker Do you know if there is an existing issue that tracks the enhancement for "Allow stand-alone usage of PlayerControlView"? This keeps coming up as a request and we should probably use one issue to track this even if we can't fully support a stand-alone version soon.

And second question - do you think it's useful to have a setter that disables minimal mode entirely? The code in useMinimalMode() looks like it should really only enter this mode if the UI overflows, but I suspect the stand-alone usage of the PlayerControlerView causes some of the values in the calculation to be off.

[icbaker]

@icbaker Do you know if there is an existing issue that tracks the enhancement for "Allow stand-alone usage of PlayerControlView"? This keeps coming up as a request and we should probably use one issue to track this even if we can't fully support a stand-alone version soon.

Let's repurpose this one.

And second question - do you think it's useful to have a setter that disables minimal mode entirely? The code in useMinimalMode() looks like it should really only enter this mode if the UI overflows, but I suspect the stand-alone usage of the PlayerControlerView causes some of the values in the calculation to be off.

When I looked into this before it was in the context of a LinearLayout, there was enough space in the layout for PlayerControlView to be in full mode, but it seemd to only 'request' enough height for minimal mode, so when it measured the available space it was 'forced' into minimal mode (from internal b/206445665). I can't tell if the same thing is happening here, but if so maybe a better solution would be to convince PlayerControlView to 'request' enough space for full mode in whatever layout context it's placed - but I think that would be part of this same "make PlayerControlView work as a standalone component" request.

[fourofspades]

@tonihei Regarding the documentation aspects.

The main issues are are around Android Auto, as the documentation there isn't using Media3. You end up following a set of documents that do things one way, then you end up at a dead end, and follow other docs that do things differently. Nothing ever links up. The code samples are a similar problem, so apps support some aspects of media playback and do things in one way, the other same apps do things differently. The migration guide has alot of gaps. Layer on top that everything is now Kotlin, trying to make sense of the docs.

Would be good to get a single set of documentation that includes Media3, Android Auto, Media Search.

[tonihei]

Thanks for the feedback - we are actively working on our documentation and the issues you describe will likely be covered by a single guide page.