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

Correctly update Chronometer in PlayerNotificationManager for playback speeds != 1.0 #6816

Closed
Cosminnv opened this issue Dec 31, 2019 · 3 comments
Assignees
Labels

Comments

@Cosminnv
Copy link

[REQUIRED] Searched documentation and issues
Searched in old issues/ google/ documentation but found nothing.

[REQUIRED] Question

I have a video playing app where you can set the speed of the video. I also have a PlayerManagerNotification to allow the user to listen while the app is in background.

Problem:
The problem is that when i change the speed of the video via PlaybackParameters the video itself works fine, but the notification current time isn't in sync with the current time of the video.

Example:
For example, if i watch a video at x2 speed for 10 real life seconds, i watch 20 seconds of the video, but the notification watch time is still at 10 seconds.

Here's my setup:
I have a single exoplayer instance binded to an AudioPlayerService. Everything is in sync and works as expected, apart from the current time when the speed is changed.

Here's how i set the Playback Speed:
Constants.player.setPlaybackParameters(new PlaybackParameters(2.0f));

I don't know if i explained that properly, if you don't understand i can register a video.

(Also Happy New Year 😋 )

@tonihei
Copy link
Collaborator

tonihei commented Dec 31, 2019

Thanks for reporting. This is in some way working as intended because Android's notification uses a Chronometer to show the current time. As you can see in the docs, this text widget is always counting in real time irrespective of the playback speed.

To avoid this problem, we should probably disable the chronometer for playbacks with speed != 1.0 in all cases. A more advanced fix is to update the time manually every second or so. I'll mark this as an enhancement to implement this feature.

@tonihei tonihei self-assigned this Dec 31, 2019
@tonihei tonihei changed the title When i set speed in PlaybackParameters the PlayerManagerNotification doesn't keep up with the real time. Correctly update Chronometer in PlayerNotificationManager for playback speeds != 1.0 Dec 31, 2019
@ojw28
Copy link
Contributor

ojw28 commented Jan 2, 2020

I think we should just disable it. I actually thought we did this already, but apparently not! The more advanced fix may still produce weird effects, depending on the UI that's on the other side.

@Cosminnv
Copy link
Author

Cosminnv commented Jan 2, 2020

Thanks for reporting. This is in some way working as intended because Android's notification uses a Chronometer to show the current time. As you can see in the docs, this text widget is always counting in real time irrespective of the playback speed.

To avoid this problem, we should probably disable the chronometer for playbacks with speed != 1.0 in all cases. A more advanced fix is to update the time manually every second or so. I'll mark this as an enhancement to implement this feature.

Oh so this isn't my fault then, i was going mad over this. Thanks for the explanation !

@ojw28 ojw28 added bug and removed enhancement labels Jan 2, 2020
ojw28 pushed a commit that referenced this issue Jan 8, 2020
This doesn't work because the Chronometer text layout can only count in realtime.

Issue:#6816
PiperOrigin-RevId: 288711702
@ojw28 ojw28 closed this as completed Jan 8, 2020
ojw28 pushed a commit that referenced this issue Jan 17, 2020
This doesn't work because the Chronometer text layout can only count in realtime.

Issue:#6816
PiperOrigin-RevId: 288711702
@google google locked and limited conversation to collaborators Mar 9, 2020
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