-
Notifications
You must be signed in to change notification settings - Fork 3
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
Wakelock for shorts is broken on android #451
Comments
Short reloads in the middle of the short and wakelock is disabled after that. This happen often on the first short on launch. |
The current logic checks each render if the active route is the
The bug happens when you navigate from the shorts screen on the homepage, to the shorts screen tab; you technically navigate away from a shorts screen, so it disables wake-lock There is basically a race condition as both shorts screens enable/disable wake-lock at the same time The solution here is probably to share some state or something |
I ended up using a simple counter to keep track of screens requiring the wakelock to be enabled |
Should be tested in version 5.6.37 |
Not fixed for me on 5.6.37+2300197 |
@KillerX Do you have reproduction steps to trigger the bug? |
Just reproduced in the most straingforward manner: Open app, Scroll down, Open short 🤷 |
The quick "flash" we see before the wakelock turns off seems to be because the short is buffering. Need to validate that to be 100% sure, but we only show the loading spinner either when the video initializes or buffers. If that is the case, the buffering somehow disables the wakelock |
The stretched image appearing could be because the player stops, but the current MediaItem is not removed from the player. shortController.player.stop(reset: false) It could also be caused by this bug: androidx/media#1237 |
For shorts that are opened from sections in homepage
The text was updated successfully, but these errors were encountered: