Varför Jellyfin-prestandan skiljer sig mellan lokala nätverk och fjärranslutningar

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why Jellyfin Performance Differs on LAN and Remote Connections

Jellyfin fungerar annorlunda på distans eftersom samma server har en mindre uppladdningskapacitet, större variationer i nätverksvägen, annorlunda routning och ofta en annan uppspelningsprofil.

En 4K-tv på trådbundet Ethernet kan spela upp en fil med hög bithastighet direkt, medan en telefon i mobilnätet får en begränsad 1080p-transkodning via en omvänd proxy eller VPN. Serverns maskinvara har inte förändrats, men klienten, den tillgängliga bithastigheten, fördröjningen och säkerhetsvägen har gjort det. De förändrade förhållandena avgör vilket arbete som utförs och skapar olika felgränser.

LAN-kapacitet bevarar vanligtvis den ursprungliga uppspelningsvägen

Ett trådbundet LAN erbjuder vanligtvis hög och stabil genomströmning samt låg fördröjning, vilket gör att kompatibla klienter kan begära originalfiler utan kvalitetsminskning. Lokal identifiering och direkt privat adressering eliminerar dessutom flera beroenden vid anslutningens upprättande.

Målet med direktuppspelning är att skicka det befintliga mediet utan att ändra det. I ett LAN gör tillräcklig bandbredd detta läge möjligt även för källbithastigheter som skulle överskrida många privata uppladdningsanslutningar.

Denna fördel försvinner på ett överbelastat Wi-Fi eller med en klient som inte kan avkoda källan. ”Lokalt” beskriver topologin, inte garanterad prestanda, så en svag trådlös länk kan fortfarande bli det långsammaste steget.

Regler för fjärruppladdning och bithastighet kan utlösa konvertering

Fjärrtrafik lämnar serverns plats via uppladdningsanslutningen, som ofta är betydligt långsammare än dess nedladdningstjänst eller LAN. Jellyfin eller klienten kan välja en lägre bithastighet, vilket kräver videokonvertering även när fjärrenheten stöder den ursprungliga kodeken.

En kapacitetsmodell med samtidiga strömmar och uppladdningshastighet visar varför varje ytterligare fjärrsession förbrukar en gemensam uppströmsbudget. Toppar i källans bithastighet kräver marginal utöver ett enkelt genomsnitt.

Konsekvensen är ett sammankopplat behov: en lägre nätverksbithastighet sparar uppladdningskapacitet men förbrukar serverberäkning. Ett lokalt inaktivt grafikprocessor kan bli belastat först när fjärranvändare ansluter.

Internetrou挺ning lägger till fördröjning, paketförluster och mellanhänder

Fjärrsessioner kan gå via internetleverantörers routning, NAT, TLS-terminering, omvända proxyservrar, mesh-VPN eller reläer. Varje komponent kan lägga till buffring, tidsgränser, begränsningar för sidhuvuden eller bandbreddsbegränsningar som inte finns mellan två LAN-adresser.

Rapporter om jämn uppspelning i LAN men buffring på distans visar att identiskt medieinnehåll och samma servermaskinvara kan ge olika resultat när nätverks- och proxyvägen ändras. Symptomet visar inte vilken mellanhand som är ansvarig.

Högre fördröjning märks tydligast vid uppstart, sökning och återhämtning efter paketförlust. Under kontinuerlig uppspelning kan tillräcklig buffring dölja fördröjningen, men den kan inte kompensera obegränsat för otillräcklig genomströmning.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

En jämförelsemetod mellan LAN och fjärranslutning

Jämförelsen blir ogiltig om klienten, den begärda kvaliteten, undertextspåret eller uppspelningsläget ändras mellan testerna. Resultat från fjärranslutning och LAN måste hålla dessa variabler konstanta innan slutsatser om nätverket dras.

Använd den fullständiga uppspelningsvägen för att särskilja lagring, konvertering och leverans. Granska sedan uppspelningsläget i instrumentpanelen tillsammans med mätningar från operativsystemet och nätverket. En separat fältrapport stöder också användning av en jämförelse mellan LAN och fjärranslutning i stället för att anta att det synliga symptomet identifierar flaskhalsen.

Testa samma enhet och fil lokalt, på distans med originalkvalitet och på distans med en fast lägre bithastighet. Registrera uppspelningsläge, transkodningshastighet, uppladdning, fördröjning, paketförlust, starttid och ombuffringshändelser. Den första variabeln som förändras när felet uppstår visar vilket lager som bör undersökas härnäst.