Skip to content

fix(player): fix Android 17 lockscreen playback and SABR seek buffering#70

Closed
Priveetee wants to merge 1 commit into
InfinityLoop1308:devfrom
Priveetee:fix/2575-lockscreen-sabr-seek
Closed

fix(player): fix Android 17 lockscreen playback and SABR seek buffering#70
Priveetee wants to merge 1 commit into
InfinityLoop1308:devfrom
Priveetee:fix/2575-lockscreen-sabr-seek

Conversation

@Priveetee

Copy link
Copy Markdown
Contributor

Fixes InfinityLoop1308/PipePipe#2575

Pairs with the extractor-side SABR cold-start fix: InfinityLoop1308/PipePipeExtractor#80

Summary

I reproduced the lockscreen/background issue on my Pixel 8 / Android 17.

There were two problems here:

  • Android 17 could lose the proper foreground/media playback state after notification updates.
  • SABR could keep an old reader position after a lockscreen MediaSession seek, so seeking forward could leave the player buffering forever.

Problem

After startForeground(), later notification updates could go through notify() instead of keeping the service foreground notification updated through startForeground().

For SABR, lockscreen seek can call seekToUs() without a new track selection. That means ExoPlayer starts asking for the new segment, but SABR was still pacing from the previous reader position.

Observed during repro:

MediaSession seek -> position around 296s
SABR waiting for a later audio segment
readerHead still around the old position
player stuck in BUFFERING

Changes

  • Keep notification updates tied to startForeground() while the player service is alive.
  • Dispose a stale media session before creating a new one.
  • Track the currently active SABR audio/video tracks in SabrMediaPeriod.
  • Prepare the SABR session position from seekToUs(), not only from track selection.

Validation

Tested on Pixel 8 / Android 17:

  • foreground playback
  • background audio
  • lockscreen play/pause
  • lockscreen seek backward
  • lockscreen seek forward
  • queue transition after lockscreen seek

Build:

  • ./gradlew :app:assembleDebug
  • git diff --check

@InfinityLoop1308

Copy link
Copy Markdown
Owner

Thanks. I just updated my p7 to 17 and also reproduced the issue.

After isolating the changes, the background audio issue is fixed by calling startForeground() again after
the player reaches STATE_READY. I found it can be solved with a minimal two-line change so this patch is unneeded.
As for the rest:

  • MediaSession: Not directly related, and should be part of the future MediaSession refactor.
  • SABR seek: Unfortunately these changes seem incorrect to me, it modify session/cache state
    outside the pump thread and treat every seek as a forward jump.

I'll close this PR since the main issue is resolved :)

@Priveetee

Copy link
Copy Markdown
Contributor Author

Thanks for the update and for digging into this :)

Great to hear the background audio issue is fixed with such a small change.
And thanks for the review on MediaSession and SABR :p

I’m totally fine with closing the PR if the main issue is resolved that's always the most important part as always !

Feel free to ping me if you want help with the future MediaSession refactor, like always np at all!

Have a great day :)

@InfinityLoop1308

InfinityLoop1308 commented Jul 3, 2026

Copy link
Copy Markdown
Owner

can you help check if playback and download works correct with logged in, including age restricted videos? I'm deal with another edge case

@Priveetee

Copy link
Copy Markdown
Contributor Author

Yeah of course, I'm on it ☺️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] Background play audio drops a few seconds after minimizing the app

2 participants