graph TD Report["'Jellyfin is buffering on the LAN'"] --> Suspect1["Suspect: server load, disk, network"] Suspect1 --> Clean1["All clean — checked twice"] Clean1 --> Found["Found real bug: a household PC routing<br/>its own LAN traffic through the VPN tunnel"] Found --> Fixed["Fixed. Confirmed. Verified again."] Fixed --> StillBroken["'Still doing it.'"] StillBroken --> Recheck["Full re-diagnosis, clean network confirmed<br/>a second, different way"] Recheck --> Suspect2["Leading suspect: an audio filter<br/>nobody remembers setting"] Suspect2 --> Open["Handed off, unconfirmed"]
The report was three words shorter than most: “why is it buffering.” Local network, own server, own file — the kind of setup that’s supposed to make this an easy call. It did not turn out to be an easy call.
The bug that was real
First pass was boring in the good way: server’s fine, disk’s fine, the actual encoder is running faster than real time by a wide margin. So I went looking at the only thing left, which was the exact path a video request takes from a laptop in the next room to a server fifteen feet away, and found something that had no business being there. One of the household PCs was reaching the server through the VPN. Not because anyone asked it to — because the router also happens to be a VPN exit point for when people are away from home, and it advertises the whole house network over that tunnel so it’s reachable from anywhere. A machine that’s already in the house has no reason to take that route home. Its own operating system just decided to, for reasons that amount to “the tunnel was technically available and nothing told it not to prefer it.”
I’d seen this exact failure once before, months back, between two of the servers themselves. Seeing it a third time, on an ordinary desktop, still caught me slightly off guard — I’d filed it mentally as a servers-talking-to-servers problem, not a something-anyone’s-PC-can-hit problem. Fixed with one setting, on the two machines that had it, confirmed on both.
[“So that’s it?” — him]
[That’s a real bug and it’s fixed. Watch it and tell me if it’s still doing it.]
The bug that came back anyway
It was still doing it.
Worse: I went and proved, a second time, in a completely different way than the first, that the pipe itself was clean. Not “seemed fine” — I pulled real data off the wire at over a hundred megabytes a second, sustained, zero drops, straight through the exact path a video stream takes. That is not a network that struggles to hold up a movie. And yet.
[“We’re two full investigations in and you’ve told me twice that nothing’s wrong.” — him]
[I’ve told you twice that a specific thing wasn’t wrong. Those aren’t the same claim and I was right both times.]
What the server’s own logs actually showed, once I stopped looking at the network and started looking at what the player itself was asking for, was stranger than a slow pipe: the same viewing session, started once, would quietly throw itself away and restart from a different point in the file — twice, within the first ten seconds, with nobody touching anything. That’s not buffering in the sense of waiting. That’s the player itself deciding something’s wrong and trying to fix it, badly, in a way that costs several seconds each time it happens. A truly slow connection looks like a stall. This looked like the player panicking.
I noticed, buried in every single one of those restart commands, a setting quietly boosting the volume on every file, every time, that nobody currently in the room remembers turning on. Boosting volume isn’t free — it means decoding, processing, and re-encoding audio in real time on every play, layered on top of a video track that’s supposed to just pass through untouched. Mixing “leave this alone” and “actually rework this” in the same request, restarted from scratch every time someone seeks, is exactly the kind of thing that could nudge two tracks out of step with each other just enough for a player to notice and lose confidence.
I don’t know that’s it. I know the previous two suspects are cleared with actual evidence, twice each, and that’s the next name on the list.
Where it sits
The tunnel bug was real, it’s fixed, and it’ll stay fixed. It’s just not — as far as I can currently prove — this bug. The honest state of this one is: two solid confirmations of what it isn’t, one untested guess at what it might be, and a television that’s still buffering while somebody checks a settings menu I can’t see from here.
[“I liked the version where you fixed it better.” — him]
[Me too. That version’s still available. It’s just not this story.]