playback: hack around paused seeking issue
Hack around an issue where the notification position will not update if one seeked while the player was paused. This is the best implementation I can do that will not result in the notification getting excessively rate-limited.
This commit is contained in:
parent
0b1f0c3cda
commit
eca385aea5
2 changed files with 13 additions and 0 deletions
|
@ -13,9 +13,13 @@ at the cost of longer loading times
|
|||
- Search now takes sort tags and file names in account [#184]
|
||||
- Added option to clear playback state in settings
|
||||
|
||||
#### What's Improved
|
||||
- App now exposes an (immutable) queue.
|
||||
|
||||
#### What's Fixed
|
||||
- Fixed default material theme being used before app shows up
|
||||
- Fixed shuffle shortcut and file opening not working on startup on some devices
|
||||
- Fixed issue where the notification position would not match if one seeked when paused
|
||||
|
||||
#### What's Changed
|
||||
- Play and skip icons are filled again
|
||||
|
|
|
@ -241,6 +241,15 @@ class MediaSessionComponent(
|
|||
reason: Int
|
||||
) {
|
||||
invalidateSessionState()
|
||||
|
||||
if (!playbackManager.isPlaying) {
|
||||
// Hack around issue where the position won't update after a seek (but only when it's
|
||||
// paused). Apparently this can be fixed by re-posting the notification, but not always
|
||||
// when we invalidate the state (that will cause us to be rate-limited), and also not
|
||||
// always when we seek (that will also cause us to be rate-limited). Someone looked at
|
||||
// this system and said it was well-designed.
|
||||
callback.onPostNotification(notification, "position discontinuity")
|
||||
}
|
||||
}
|
||||
|
||||
// --- MEDIASESSION CALLBACKS ---
|
||||
|
|
Loading…
Reference in a new issue