IssueTracker

I observed the same issues on Samsung Galaxy III phone with OS 4.1.1 and on Samsung Galaxy tablet with OS4.0.4. Both onInfo and onBufferingUpdate are never called.

Does anybody make a workaround for this bug?

I found the workaround for this bug.
mRunnable = new Runnable() {

                        @Override
                        public void run() {
                                if (mVideoView.getCurrentPosition() != 0) {
                                        mLoadingView.setVisibility(View.GONE);
                                        mHandler.removeCallbacks(this);
                                } else {
                                        mHandler.postDelayed(this, 500);
                                }
                        }

                };
                mHandler.postDelayed(mRunnable, 500);

The workaround in comment #3 assumes that you only buffer during the beginning of the video. That is not always the case. For example, if the bandwidth drops after the initial buffering, then the buffering event should fire again.

There is a workaround but it is very convoluted.

Basically, you would poll the current position and compare it with the last 2-5 previous values. If the values are not changing, you are either buffering or paused.

To distinguish between these two possibilities, you need to be notified when the player is paused. If the player was not paused, then you must be buffering. Problem is that MediaPlayer has no pause listener. And the MediaController manages the pause state internally.

To workaround the pause notification, have a look at:
   http://stackoverflow.com/questions/7934556/event-for-videoview-playback-state-or-mediacontroller-play-pause

The idea is that you override the MediaPlayer or VideoView so that when MediaController calls the pause api, you intercept this call with your overridden method, note the paused state, and then actually pause the player by calling super's method.

This ugly hack is very burdensome. I would encourage you to star this bug and raise awareness of android developers so this gets fixed the proper way. Thanks.

Thanks for the fully workaround!
But I don't think Google is gonna fix this since HLS has been abandoned.

Any fix for this? thanks

Is there any solution for this issue? :(

HLS is still the predominant method for streaming video.  Ticket should not be marked obsolete.

I think this was marked obsolete due to the recent delivery of NuPlayer in Android 5.0 to replace AwesomePlayer.  Since e...@google.com did not provide any information, we can only wonder.

It triggers, try code below:

videoView.setOnPreparedListener(new MediaPlayer.OnPreparedListener() {
            @Override
            public void onPrepared(MediaPlayer mediaPlayer) {
                mediaPlayer.setOnInfoListener(new MediaPlayer.OnInfoListener() {
                    @Override
                    public boolean onInfo(MediaPlayer mp, int what, int extra) {
                        if (what == MediaPlayer.MEDIA_INFO_BUFFERING_END){
                            progressDialog.dismiss();
                            return true;
                        } else if(what == MediaPlayer.MEDIA_INFO_BUFFERING_START){
                            progressDialog.show();
                        }
                        return false;
                    }
                });
                progressDialog.dismiss();
                videoView.start();
            }
        });

I still can't get this working with SDK 26.  I'm using it on Android Wear if that makes a difference.  Doesn't matter if OnInfoListener is inside of OnPreparedListener or outside, it's never hit.

Damn, that's sad. Wanted to switch to streaming radio through HLS because it's much faster than RTSP, but this bug is a dealbreaker :/