You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Show HLS stream in media notification as a progressive stream (without the "live window") #1256
From my understanding, the adaptive is the relative "new kid" on the block, offering that live window seek functionality and that awesome wave visual effect.
Call me old-fashioned, but I just hate seeing a seekable timeline on a LIVE audio stream.
It rubs me the wrong way.
In my opinion, it should only be on audio that is finished (a file). Less confusion.
So my question is - is it possible to play an HLS stream, but WITHOUT that live window?
To make it look like it is a progressive livestream?
(I mean I know it can be because one of my old apps can do it, but it was not built with "media3")
Yes, I agree the seekbar for a live window doesn't make sense in the notification. The fix for this is to not set the duration when syncing the Media3 session state to the platform metadata data.
When testing this works for System UI media controls on API 29 and API 33. The seekbar is shown starting with API 29 I think and only for media style notification that have a session attached (which is standard with DefaultMediaNotificationProvider). Hence this only needs to be changed in the MediaSessionLegacyStub where we can set C.TIME_UNSET if it's a live stream.
I'll mark this issue as an enhancement and send such a change to the internal review. The commit will be referenced here when it lands on GitHub.
@tonihei any update on this issue please? will this fix be part of 1.6.0 release?
A live window with changing duration can't be properly displayed in a media notification. The duration constantly changes and creates a nervous jumping seekbar that is not really useful. This change sets the duration for live streams to C.TIME_UNSET when publishing the player state to the platform session. This way no duration is sent to the platform session which prevents media controls from drawing a seekbar.
What you mention above is when using MediaSessionCompat I assume. But what about MediaSession (if we don't have the fix)?
Activity
marcbaechinger commentedon Apr 9, 2024
Thanks for reporting!
Yes, I agree the seekbar for a live window doesn't make sense in the notification. The fix for this is to not set the duration when syncing the Media3 session state to the platform metadata data.
When testing this works for System UI media controls on API 29 and API 33. The seekbar is shown starting with API 29 I think and only for media style notification that have a session attached (which is standard with
DefaultMediaNotificationProvider). Hence this only needs to be changed in theMediaSessionLegacyStubwhere we can setC.TIME_UNSETif it's a live stream.I'll mark this issue as an enhancement and send such a change to the internal review. The commit will be referenced here when it lands on GitHub.
Do not set a duration for live streams
fabricegen commentedon Mar 26, 2025
@tonihei any update on this issue please? will this fix be part of 1.6.0 release?
A live window with changing duration can't be properly displayed in a media notification. The duration constantly changes and creates a nervous jumping seekbar that is not really useful. This change sets the duration for live streams toC.TIME_UNSETwhen publishing the player state to the platform session. This way no duration is sent to the platform session which prevents media controls from drawing a seekbar.What you mention above is when using
MediaSessionCompatI assume. But what aboutMediaSession(if we don't have the fix)?