Why streaming apps forget where you stopped

You paused at the reveal. Tonight the movie resumes ten minutes before it, in a scene you have already watched twice. On your phone it is at the beginning. On the TV it is, somehow, further along than you ever got.

Nothing is wrong with your account. Something is wrong with a number, and the number is doing its best under conditions it was never going to win.

Your position is a message, not a fact

It feels as though the service knows where you are, the way a bookmark knows which page it is in. It does not. The player on your device knows where you are. The server knows where you were the last time the player told it.

The player reports in every so often, and at moments it considers worth a report, which usually means pausing, stopping, or closing the app the polite way. Between reports the server is holding an old number. Swipe the app away, walk out of signal, let the phone die, and the last report is the one that stands. Everything you watched after it was never written down.

That is the whole of the first mystery. The service did not lose your place. It never had it.

Two devices, one movie, and no referee

The second mystery needs a second device.

You watch on the sofa, stop, then finish on the train. Each device is a separate client with its own idea of where you are, and both are writing to the same record. Nothing sits between them deciding who is right. Each reports what it has, when it can.

The property a system like this actually offers has a name. Werner Vogels, in a 2009 article in Communications of the ACM, defined an eventually consistent system as one that ensures that if no new updates are made to a given data item, eventually all reads of that item will return the last updated value. Read the conditions in that sentence carefully. Eventually. If no new updates. Two devices, one of them still playing, is precisely the situation where neither condition holds.

Last write wins, and last is a guess

So when two reports disagree, something has to choose.

The cheap way is to keep whichever arrived with the newer timestamp. The 2007 paper describing Amazon’s Dynamo store, which is where much of modern thinking on this comes from, names it plainly: when a system cannot tell which of two versions came first, it can only use simple policies such as last write wins. The same paper describes the careful alternative, using vector clocks to capture the causal order of versions so the system knows one write genuinely followed another rather than guessing from a clock.

Most consumer players take the cheap way, because the position of a movie is not a bank balance. And the cheap way has a hidden dependency. The timestamp comes from the device, and the device’s idea of the time comes from its clock. Clocks are kept close by NTP, defined for its current version in RFC 5905 in 2010, but close is not identical. A phone that has been asleep, a TV that has not synced since it was set up, a laptop that crossed a time zone, each can be a little ahead or behind.

Which means a device can win the tie with an older position, simply because it thinks it is later than it is.

Why it goes backwards more than forwards

Notice that every mechanism so far pushes in the same direction.

A missed final report loses you the last stretch. A tie won by the wrong device sends you back to where that device had got to. Both errors land you earlier in the movie than you were. The rare case where you land later is the tie going the other way, when the device that had got further also had the newer stamp, and that is the one you never notice because it feels correct.

There is one deliberate backward step on top of the accidental ones. Many players resume a little before the stored position on purpose, so you land in the run-up to where you stopped rather than mid-sentence. It is a good decision that happens to look exactly like the bad ones.

Why it thinks you finished

The reset to zero is a different mechanism with a more defensible reason.

A service has to decide when a movie counts as watched, and it cannot wait for the final frame, because almost nobody watches to the final frame. So it picks a threshold near the end, usually somewhere in the credits, and once playback crosses it the movie is marked done and the saved position is cleared. That is what feeds the watched list and what keeps a finished movie out of the continue-watching row.

Stop during a long credits sequence, or wait for a mid-credits scene and then close the app, and you have crossed the threshold without finishing. From the service’s point of view you are done. From yours, the movie has forgotten you.

Offline is the hardest case

A downloaded movie makes every part of this worse at once.

Nothing is reported while you watch, because there is nowhere to report to. When the device comes back online it sends what it has, which may be hours old, and if another device has reported in the meantime the two collide and the tie-break runs on stamps that were set on a plane. The offline device is usually the one that has got furthest, and it is also the one most likely to lose.

Getting your place back

None of this is fixable from the sofa, but most of it is avoidable.

Pause before you leave. Pause is a moment nearly every player reports immediately. Swiping the app away is not. Pause, count to five, then close.

One device per sitting. The conflicts need two writers. If the phone finished the movie, let the phone be the one that says so before the TV is opened.

Reconnect before you switch. After watching offline, let the device sit online for a minute before opening the same movie elsewhere, so its report lands first.

Do not stop in the credits. If you want the mid-credits scene, watch it to the end. If you do not, stop before the credits begin and the position survives.

Scrub, do not rewatch. If it resets to zero, the movie is not gone, only the number. Drag to where you were and let the player report the new position.

That last one is a useful way to think about all of it. The movie was never lost. What went missing was a message, sent by a device that did not know it was the last one it would send.