Slow starts and buffering

There are two different complaints here, with different causes.

A film takes a long time to start

This is almost always the shape of the file plus how fast your provider serves it.

Before a film can show its first frame, the player has to fetch the part of the file that says where everything inside it is. In a typical provider film that part is large and sits at the far end of the file, so there is a wait before anything appears, and how long it lasts depends almost entirely on your provider.

On a weak link a large film can take twenty seconds to start. That is the shape of the file and the speed of the provider, not something wrong with the app.

What helps

• A better connection to the provider. This is the one thing that really changes it, and the app already does what it can at its end without being asked.
• A smaller file. Where a provider offers the same title more than once, the lighter version starts sooner. Try Versions on the title.

What does not help

No buffer setting will change it. The buffer decides how much is held once data arrives, not how fast it arrives. If somebody tells you to raise the buffer to fix a slow start, they are wrong.

How to tell a slow start from slow seeking

Look at the total time on the seek bar. While it still says 0:00, the index has not been read yet. That is a start, not a seek.

It plays, then stops to buffer

That is throughput during playback.

• A live channel rebuffering every few seconds on a connection that is otherwise fine is usually the provider’s edge, not you. A different version of the channel often runs on a different edge, try Versions in the player.
• A film that buffers in bursts benefits from a larger buffer: Settings → Player → Buffer size. This is the one case where that setting genuinely helps.
• Everything buffering on Wi-Fi at the far end of the house is the Wi-Fi.

Seeking is slow in a film

Every jump asks the provider to start serving the film from a new place, so a slow provider is slow again at each jump. The app is built to pick straight back up rather than easing in from nothing.

In a catch-up stream, seeking is different by nature: a jump lands near where you dropped the marker rather than exactly on it, and plays on from there.

The app itself is slow, not the video

Different problem. A very large playlist makes the first open of a screen slow while the catalogue is indexed. It settles. If it does not, trimming categories is the lever with the biggest effect.