[Feature request] Allow media controller to see full duration of clipped item

[Digipom]

[Feature request] Allow media controller to see full duration of clipped item

[Tolriq]

Glad I subscribed to this thread and discovered the createMessage API too.

https://developer.android.com/media/media3/exoplayer/listening-to-player-events

@tonihei is there a way to keep a reference to the message to change it's setDeleteAfterDelivery value after sending it?

Usage is the same as OP, I have users who want to be able to repeat A-B section of media, but should also be easily able to remove the repeat at any moment, would be nice to be able to embrace setDeleteAfterDelivery and not manually resend a message when they are on repeat mode all.

[Tolriq]

This is an old user request, but I think as OP the notification and everything should still show the full media value.

Just when then user select repeat mode A-B he can move 2 bars in the player to select the points.

Anyway yes I can resend the message as needed, thanks, wonder how I missed that API.

[tonihei]

ClippingConfiguration also works, but it also alters the duration and timebase of the clipped audio such that it starts at 00:00, and has a duration equal to the clipped segment. This isn't desirable when the clipping is done through a UI based on user selection.

Is this a problem because you are using Media3's default PlayerView and can't achieve the desired UI? I assume when you are writing your own UI, you can design it in any way you'd like.

Polling mediaPosition can work but is error-prone and leads to verbose code

I wouldn't recommend it for looping, but if you'd like to trigger something at a certain playback position, you can use timed messages:

exoPlayer.createMessage(yourHandler)
    .setLooper(player.getApplicationLooper()) // needed if you want to do something with your player here
    .setPosition(targetPositionMs)
    .send()

[Digipom]

@tonihei We're using our own UI, but adding a clip configuration also modifies duration and seeking behavior. Even if we somehow fake that in our own UI, the notification would still behave in this way.

Interesting about the message -- wasn't aware of this API. For now we actually did handle this via polling but will check that out. Thanks!

[tonihei]

but adding a clip configuration also modifies duration and seeking behavior. Even if we somehow fake that in our own UI,

Yes, you would need to adjust the duration/position yourself in this case.

the notification would still behave in this way

This is interesting, because you can't easily control that even if you wanted to. I can mark it as a feature request to allow this conversion to use the full duration without the clipping. We probably treat it as low priority for now though as you can workaround it yourself it seems. We also need additional metadata about the full item duration which we don't have at the moment.

[Digipom]

@tonihei Definitely, it could be configurable as there are at least two use cases here -- either clipping to a segment and making that the new media, or looping between A and B without clipping.

I think for our use case, the message handler might actually work well since we don't need looping to exact frame positions (I can see how that might be useful for others though). Depends on how much latency there is vs polling -- will have to test!

[tonihei]

@Tolriq: Do you also care about how this clipping is displayed in media notifications? If not, I suspect you are looking for a feature to change the clipping positions at run time (tracked by google/ExoPlayer#3163 still).

To your actual question: the message properties can't be changed after sending it as this is a bit unpredictable. I think you could solve this yourself though by just resending a message when receiving the last one if needed (and always using the default deleterAfterDelivery==false.