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

Audio stream moved to buffering state immediately on disconnection of internet #1606

Closed
wajidp opened this issue Jun 19, 2016 · 12 comments
Closed
Assignees
Labels

Comments

@wajidp
Copy link

wajidp commented Jun 19, 2016

Am trying to play an icecast stream, when my internet is turned off, the player goes to buffering state immediately. I was wondering why the stream is not getting buffered in the device with the exoplayer.
With mediaplayer api the stream is played for around 1 minute before it dies.
Am i missing somethings my bufferms=4000 and minrefbuffer is 0

http://stream.peaceradio.com:8000/low

@wajidp
Copy link
Author

wajidp commented Jun 19, 2016

I need to get the stream downloaded from the next minute atleast. Is it possible?

@ojw28
Copy link
Contributor

ojw28 commented Mar 16, 2017

This is a feature request to avoid immediate retry for live streams in ExtractorMediaPeriod. It would be better to wait until the player can make no further progress before triggering the retry.

@BMarton
Copy link

BMarton commented Sep 21, 2017

Any progress on this issue?

@janeriksamsonsen
Copy link

Yeah, is this a prioritized feature? It should be...

@ojw28
Copy link
Contributor

ojw28 commented Oct 18, 2017

This is scheduled to be fixed by end of year (or shortly thereafter).

@janeriksamsonsen
Copy link

@ojw28 - excellent! 👍

@viaductit
Copy link

viaductit commented Oct 21, 2017

I have tried the r2.5.4, still not working. The issue was reported one year ago and will be fixed next year?? Is no quick fix possible until there is an official fix? This should be a high prio bug becuase it is realy bad for the user experience. We have 500k users and a lot of complains regarding this issue :-S

@janeriksamsonsen
Copy link

Any more information about when this will be implemented?

@ojw28
Copy link
Contributor

ojw28 commented Jan 18, 2018

I have a change that implements this, but it's so hacky I don't think it can be submitted in its current form. We need a little more time to try and come up with something better.

@janeriksamsonsen
Copy link

@ojw28, thanks for responding. Is the "fix" available in a feature-branch which I can use until waiting for the final solution?

@ojw28
Copy link
Contributor

ojw28 commented Jan 23, 2018

Not currently, but we should have something to share this week.

ojw28 added a commit that referenced this issue Jan 24, 2018
Issue: #1606

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183058160
@ojw28
Copy link
Contributor

ojw28 commented Jan 24, 2018

This should be fixed in dev-v2. Please give it a try.

Note that if the connection is broken, there will always be an audible discontinuity when the retry happens, even if the network is good again at that point. The way these streams work isn't designed to allow seamless re-joins. The best way to deliver audio to mobile devices is to use a more appropriate streaming technology such as DASH or HLS, for which this issue does not apply.

@ojw28 ojw28 closed this as completed Feb 16, 2018
@google google locked and limited conversation to collaborators Jun 29, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants