Fixed small bug in cached play offset
This commit is contained in:
parent
35b77c75fe
commit
a16f00a42b
1 changed files with 6 additions and 2 deletions
|
|
@ -272,11 +272,15 @@ class RecordingListViewModel(app: Application) : AndroidViewModel(app) {
|
||||||
}
|
}
|
||||||
|
|
||||||
// Throttled persistence of the current track + offset: at most once per
|
// Throttled persistence of the current track + offset: at most once per
|
||||||
// second, and only while a track is loaded. Saving live (every 200ms
|
// second, and only while a track is actively PLAYING. Saving while paused
|
||||||
// position tick) would hammer DataStore; 1s is plenty for resume.
|
// is both unnecessary (a paused position doesn't change) and harmful: on
|
||||||
|
// restore, preparePaused seeks asynchronously, so ExoPlayer briefly reports
|
||||||
|
// position 0 before the seek lands — saving during that window would clobber
|
||||||
|
// the good offset with 0. Gating on isPlaying closes that window.
|
||||||
viewModelScope.launch {
|
viewModelScope.launch {
|
||||||
var lastSaveAt = 0L
|
var lastSaveAt = 0L
|
||||||
playbackState.collect { s ->
|
playbackState.collect { s ->
|
||||||
|
if (!s.isPlaying) return@collect
|
||||||
val id = s.nowPlayingId ?: return@collect
|
val id = s.nowPlayingId ?: return@collect
|
||||||
val now = System.currentTimeMillis()
|
val now = System.currentTimeMillis()
|
||||||
if (now - lastSaveAt >= 1000L) {
|
if (now - lastSaveAt >= 1000L) {
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue