Waarom de prestaties van Jellyfin verschillen op lokale en externe verbindingen

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Why Jellyfin Performance Differs on LAN and Remote Connections

Jellyfin presteert op afstand anders omdat dezelfde server te maken krijgt met een kleiner uploadbudget, grotere variatie in de verbindingsroute, andere routering en vaak een ander afspeelprofiel.

Een 4K-televisie via bekabeld Ethernet kan een bestand met een hoge bitsnelheid rechtstreeks afspelen, terwijl een telefoon via mobiel internet een tot 1080p begrensde transcodering via een reverseproxy of VPN ontvangt. De serverhardware is niet veranderd, maar de client, beschikbare bitsnelheid, latentie en beveiligde route wel. Door die gewijzigde omstandigheden wordt ander werk uitgevoerd en ontstaan andere storingsgrenzen.

LAN-capaciteit behoudt doorgaans het oorspronkelijke afspeelpad

Een bekabeld LAN biedt doorgaans een hoge, stabiele doorvoersnelheid en een lage vertraging, waardoor compatibele clients de originele bestanden kunnen opvragen zonder kwaliteitsverlies. Lokale ontdekking en directe private adressering nemen bovendien verschillende afhankelijkheden bij het tot stand brengen van de verbinding weg.

Het doel van Direct Play is om de bestaande media ongewijzigd te verzenden. Op een LAN maakt voldoende bandbreedte deze modus haalbaar voor bronbitsnelheden die de uploadverbinding van veel huishoudens zouden overschrijden.

Dit voordeel verdwijnt bij overbelaste wifi of wanneer een client de bron niet kan decoderen. ‘Lokaal’ beschrijft de topologie, niet de gegarandeerde prestaties. Een zwakke draadloze verbinding kan dus nog steeds de traagste schakel worden.

Regels voor externe uploads en bitsnelheid kunnen conversie activeren

Extern verkeer verlaat de locatie van de server via de uploadverbinding, die vaak veel trager is dan de downloadservice of het LAN. Jellyfin of de client kan een lagere bitsnelheid kiezen, waardoor videoconversie nodig is, zelfs wanneer het externe apparaat de oorspronkelijke codec ondersteunt.

Een capaciteitsmodel op basis van gelijktijdige streams en uploadsnelheid laat zien waarom elke extra externe sessie een gedeeld upstreambudget verbruikt. Piekwaarden van de bronbitsnelheid vereisen extra marge bovenop een eenvoudig gemiddelde.

Het gevolg is een gekoppelde vraag: een lagere netwerkbitsnelheid bespaart uploadcapaciteit, maar verbruikt serverrekenkracht. Een lokaal ongebruikte GPU kan pas druk worden wanneer externe gebruikers verbinding maken.

Internetroutering voegt vertraging, verlies en tussenstations toe

Externe sessies kunnen via ISP-routering, NAT, TLS-terminatie, reverseproxies, mesh-VPN’s of relais lopen. Elk onderdeel kan buffering, time-outs, beperkingen op headers of bandbreedtebeperkingen toevoegen die niet bestaan tussen twee LAN-adressen.

Meldingen van vloeiende weergave op het LAN maar buffering op afstand laten zien dat identieke media en serverhardware zich anders kunnen gedragen zodra de netwerk- en proxyroute verandert. Het symptoom wijst niet aan welke tussenpartij verantwoordelijk is.

Een hogere latentie is het duidelijkst bij het starten, zoeken en herstellen na pakketverlies. Tijdens stabiel afspelen kan voldoende buffering de vertraging maskeren, maar buffering kan een ontoereikende doorvoersnelheid niet onbeperkt compenseren.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Een vergelijkingsprotocol voor LAN en externe verbindingen

De vergelijking is ongeldig als de client, gevraagde kwaliteit, ondertiteltrack of afspeelmodus tussen de tests verandert. Bij resultaten van externe verbindingen en het LAN moeten deze variabelen gelijk blijven voordat conclusies over het netwerk worden getrokken.

Gebruik het end-to-end-afspeelpad om opslag, conversie en levering afzonderlijk te labelen. Bekijk vervolgens de afspeelmodus in het dashboard naast metingen van het besturingssysteem en het netwerk. Een afzonderlijk praktijkrapport ondersteunt ook het gebruik van een vergelijking tussen LAN en externe verbinding in plaats van aan te nemen dat het zichtbare symptoom de bottleneck aanwijst.

Test hetzelfde apparaat en bestand lokaal, op afstand met de oorspronkelijke kwaliteit en op afstand met een vaste lagere bitsnelheid. Noteer de afspeelmodus, transcodeersnelheid, upload, latentie, pakketverlies, opstarttijd en gebeurtenissen waarbij de stream opnieuw moet bufferen. De eerste variabele die samen met de storing verandert, bepaalt welke volgende laag moet worden onderzocht.