UI components: customize fast forward / rewind

[PaulWoitaschek]

I'm developing an audibook player and I try to make use of the MediaSessionConnector.

Audiobooks may be split in several chapters and chapter marks so they present themselfes as a list of tracks. From the listening perspective audiobooks are more of a single piece of media where you usually start at the beginning and listen linearly to the end. Therefore I don't show the next/previous buttons but only fast forward / rewind.

This means that if the users presses rewind, I want to rewind by 20 seconds. It doesn't matter where exactly in the audiobook I am.

For example: I am in chapter 20, second 5. If I now press rewind, I want to seek to Chapter 19 at 15 seconds before the ending.

It would be really helpful to being able to overwrite that behavior.

[ojw28]

This isn't specific to MediaSessionConnector. The same feature request equally applies to PlayerControlView and PlayerNotificationManager too.

[ojw28]

Note: https://github.com/google/ExoPlayer/issues/6926 is quite closely related to this request as well.

[ojw28]

@marcbaechinger - As discussed, it might be nice to move the next, previous, fast-forward and rewind functionality that's currently duplicated in all of our UI components into ControlDispatcher to address this and the issue referenced above (doing so addresses these issues because an application can provide a custom ControlDispatcher that implements the functionality in a different way).

[PaulWoitaschek]

@ojw28 is it even possible at all to seek to sth like: previusWindowIndex, previousWindowDuration - time? Or can I only get the duration of the current window and would need to first seek to the previous window and then set the position with the new duration?

[ojw28]

Good point, it might not be possible to do it this way. Although it would be a nice change to make regardless.

[ojw28]

@ojw28 is it even possible at all to seek to sth like: previousWindowIndex, previousWindowDuration - time? Or can I only get the duration of the current window and would need to first seek to the previous window and then set the position with the new duration?

Regarding this point:

1. If you have metadata that defines the chapter durations, then you'll be able to calculate the desired seek position directly even if the duration of the window isn't know to the player.
2. If you don't have metadata, it's probably possible for you to implement a ControlDispatcher that kicks off a more complicated flow for doing the logic you describe. It is of course significantly more complicated, but I think it should be possible.
3. If you don't have metadata, and want a simpler solution than (2), then I think the remaining missing piece is just the ability to specify a seek position relative to the end of the media rather than the start. This is specifically useful prior to the player knowing the duration, and if you don't have duration metadata from somewhere else, and even in this case I think it's more of a simplification rather than a hard requirement.

I think the bulk of the request here was satisfied by the ControlDispatcher change, so I'm going to close it. If you think (3) adds significant value then please do file a separate bug specifically for that request, and we can use that for tracking. Thanks!