Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guidance on Playback Position persistance #236

Closed
PaulWoitaschek opened this issue Dec 29, 2022 · 7 comments
Closed

Guidance on Playback Position persistance #236

PaulWoitaschek opened this issue Dec 29, 2022 · 7 comments
Assignees
Labels

Comments

@PaulWoitaschek
Copy link
Contributor

PaulWoitaschek commented Dec 29, 2022

Problem

I'm currently trying to migrate my audiobook player Voice to media3 session, but I'm having a difficult time doing so. The main problem is that media3 seems to be designed primarily for music playback, with the assumption that the user can freely browse and play individual tracks. However, in the audiobook (or podcast) use case, the user wants to play a book as a whole, rather than individual tracks. Additionally, the user wants the ability to resume playback from where they left off.

Example

When interacting with android auto, which uses the legacy media APIs and calls onPlayFromMediaId, media3 internally calls onAddMediaItems with a searchQuery and prepares and plays the first track of the audiobook. This doesn't meet the needs of the audiobook use case, as the user does not want to start playback at the beginning of the book every time.

Solution

I would love to get some guidance on how media3 is supposed to work with use cases that involve persisting the playback position. It would be helpful to have more information on how media3 is intended to be used in scenarios like audiobook playback, where the user wants to play a book as a whole and maintain their position within the book.

@marcbaechinger
Copy link
Contributor

We are aware that the use case of Android Auto is not yet possible. We are working on an enhancement of onAddMediaItems that allows to expand a single item/search to a list of item and also specify the start index and position in that index (see also #156).

Besides this, an app needs to persist the playlist (list of media IDs), the current media item and the position in that media item itself. This probably happens when the service (or the activity housing the player) is destroyed or oat another moment that makes sense for the app. Then when playback is resumed, the app needs to add the items of the playlist to the player, prepare and start playback.

With the Media3 API this would be something like:

player.setMediaItems(listOfMediaItems, startIndex, startPositionMs);
player.prepare();
player.play();

@vanniktech
Copy link

vanniktech commented Jan 3, 2023

It is possible. I do use media3 with Android Auto in https://play.google.com/store/apps/details?id=com.vanniktech.rssreader

Edit: But yeah, I have to work around it by using the API's you've described and also checking whether the play list has changed or not.

@marcbaechinger
Copy link
Contributor

Thanks Niklas! Yeah, I wasn't clear. What I meant with the use case of Android Auto is that it is not possible to expand from a single item sent by a legacy API call like playFromMediaId() to a list of items and then start playback at a different windowIndex then 0.

@vanniktech
Copy link

Oh yes. I work around that by reshuffling the list so that my dedicated item is at 0 even if it should be at another index ..

@PaulWoitaschek
Copy link
Contributor Author

We are aware that the use case of Android Auto is not yet possible. We are working on an enhancement of onAddMediaItems that allows to expand a single item/search to a list of item and also specify the start index and position in that index (see also #156).

Is there any timeline for this? I'd like to be an early adopter of media3 but with the current limitations I would need to drop the Android Auto support.
Or is there alternatively a way to overwrite the legacy callbacks and handle it myself?

Besides this, an app needs to persist the playlist (list of media IDs), ...

Yes, that's clear. The question was more targeting Android Auto and how other Apps interact with the media session that I provide.
Let's assume one day Android Auto no longer uses the legacy apis. How would it handle the playback? How would I ensure that it does not prepare the media items with a position of zero but rather picks up my locally persisted playback position?

@vanniktech
Copy link

Oh another fun thing that I remember is this one. Had to also work around the fact that extras are null. Ended up working around that by putting a JSON string as my mediaId which contains some data and then I'm able to interact with it ...

@marcbaechinger
Copy link
Contributor

[..] Android Auto no longer uses the legacy apis. How would it handle the playback? How would I ensure that it does not prepare the media items with a position of zero but rather picks up my locally persisted playback position?

I don't know how Auto will use the new API. That's up to them. They could do a similar thing like they do today and let the app set the start position.

The user browses the media library you provide and then selects an item. AA could call

player.setMediaItem(mediaItem);
player.prepare();
player.play();

This would then call your callback with the media item selected and leaves it to the app to for instance expand the item to a list of items and to select the start index and position. The new MediaSession.Callback method mentioned above will allow this to provide the feature requested with #156.

Is there any timeline for this?

I think this will be included in the next release. Can't tell when that actually will be but probably Jan/Feb.

I'm closing this issue as a duplicate of #156. Please re-open if you think there's something to add.

@androidx androidx locked and limited conversation to collaborators Mar 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants