标签：#media3

Our app ships long video lessons. Twenty to forty minutes each, watched mostly on hostel wifi and mobile data with two bars. Streaming video looks like a solved problem when you build the happy path. You wire up ExoPlayer, point it at a stream, it plays. Then real students open it on devices you have never held, and your bug tracker starts filling up with one line: "video not playing." That line turned out to be four unrelated problems. Here's what I actually learned. ## Buffering is the bug you feel before you see an error Nobody waits out a bad connection during a 35-minute lecture. On a 15-second reel a stall is annoying. In a lecture, a stall every two minutes means the student closes the app and studies from a PDF instead. So the real question was never "does it play." It was "what happens when the network stops cooperating for four seconds." Three situations broke us repeatedly: Wifi to mobile data handover mid-lesson Bandwidth that is technically connected but useless Short total drops, three to ten seconds, that should not end playback ExoPlayer gives you everything you need here. Adaptive bitrate, a configurable LoadControl , player listeners. The catch is that the defaults are tuned for general media, not for a 40-minute lecture on a bad link. What moved the numbers for us: Bigger buffers, deliberately. DefaultLoadControl.Builder().setBufferDurationsMs(...) takes a min buffer, a max buffer, the buffer needed to start playback, and the buffer needed to resume after a rebuffer. That last parameter is the interesting one. Raising it costs you a little extra time on resume and buys you far fewer repeat stalls, because the player stops trying to restart on a nearly empty buffer. Telling the user the truth. Our first version showed a spinner and nothing else. A spinner with no context reads as "the app is frozen," so students force-closed and reopened, which threw away the buffer and made everything worse. Saying "reconnecting" instead of spinning silently cut t