Skip to content
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

isLive flag for streams #1401

Open
WieFel opened this issue Feb 5, 2025 · 4 comments
Open

isLive flag for streams #1401

WieFel opened this issue Feb 5, 2025 · 4 comments
Assignees
Labels
1 backlog enhancement New feature or request

Comments

@WieFel
Copy link

WieFel commented Feb 5, 2025

Is your feature request related to a problem? Please describe.
I have spent a few days already trying to implement an isLive flag in my radio live stream player, but without success. I am playing one simple audio source, a radio stream.

Describe the solution you'd like
It would be really helpful if the audio player had a flag isLive which is true, when the player is currently playing live, and false if the player is a little behind in time (e.g. when the user paused and resumed the stream)

Describe alternatives you've considered
I tried several approaches:

  • inferring the live state from the playerStateStream, e.g. setting isLive=true if the player is in the ready state and is playing, but this is obviously not correct. if the player is paused and resumed, it already breaks
  • i tried to hold a flag myself for isFirstStart, which is set to true initially. Once the user presses play, i do isLive=isFirstStart and set isFirstStart=false at the same time. But this is also not working for all cases, as the sequence of the states loading, buffering and ready is very random between Android and iOS.
    On Android, for example, it goes from loading to ready (playing=false) directly, and after pressing play, to ready (playing=true, which is fine).
    Where on iOS, the sequence is loading, buffering, ready (with playing=false), and then when pressing play: ready (playing=true, this is where i set isLive=isFirstStart and reset my flag isFirstStart=false), buffering (again?), ready (playing=true, here my isFirstStart is already false, so the isLive flag is directly back at false)
  • inferring the isLive from the positionStream. i.e. always when the position value is e.g. < 1 second and playing==true, i set isLive to true. which works fine on android. BUT, on iOS, the positionStream is just never getting any event, not even once. is this desired?

is there anything else I could try?
it would be really convenient if the audio player could offer an isLive flag directly

@WieFel WieFel added 1 backlog enhancement New feature or request labels Feb 5, 2025
@ryanheise
Copy link
Owner

Could you do this by monitoring the position and duration?

@WieFel
Copy link
Author

WieFel commented Feb 6, 2025

Thanks for the response @ryanheise!

It is very complicated to infer the correct isLive state from these streams, as they behave totally different on Android and iOS:
positionStream:

  • Android: continuously gives position updates, like it should be
  • iOS: is triggered 1x before the first play(), with position 00:00:00. Then again 2x when pausing the player, with the current position

durationStream:

  • Android: is triggered 1x before the first play(), with position null, then never again
  • iOS: is triggered 2x before the first play(), with position 00:00:00, then never again

I have been trying for a while but I couldn't make it work. Any other ideas?

@ryanheise
Copy link
Owner

It sounds like an issue that positionStream and durationStream are not updating accurately on live streams, and fixing this might allow you to implement the logic you require. In that case, the way forward would be to fix this.

@WieFel
Copy link
Author

WieFel commented Feb 7, 2025

@ryanheise ok, i can create a separate bug ticket if you want.

another solution to determine isLive would be providing a stream that yields play, pause, stop events, triggered by the user. right now, i can of course track these events from the play/pause/stop button within my app, BUT when the user uses the notification play/pause button (from just_audio_background), this principle breaks again. That's why a stream for the user-triggered play/pause/stop events could help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 backlog enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants