Hoeveel gelijktijdige Jellyfin-streams kan een homeserver aan voordat het afspelen hapert?

Jellyfin heeft geen universeel aantal streams; duurzame gelijktijdigheid eindigt wanneer de zwaarste normale werklast herhaaldelijk de buffermarge van de client verbruikt.

Een thuisserver met zes voornamelijk Direct Play-clients kan minder belast worden dan één externe HDR-stream met ingebakken ondertiteling. Meet de afspeelmodi, conversiestappen en concurrerende services die tijdens het drukste normale tijdvenster overlappen. Het resultaat is een praktische bovengrens die aan je werklast is gekoppeld, in plaats van aan een misleidende regel voor gebruikers per CPU.

Tel afspeelmodi in plaats van gebruikers

Elke Jellyfin-sessie volgt een ander pad: Direct Play leest en verzendt voornamelijk het bestand, terwijl remuxen, audioconversie en videotranscodering steeds meer werk toevoegen. Sessies tellen zonder hun paden te classificeren verbergt de werkelijke invoer voor de mediapijplijn.

Een nuttige werklasttabel legt voor elke representatieve client en elk bronbestand de transcoderingswerklast vast, inclusief codec, HDR-status, ondertiteling, resolutie en externe bitrate.

De telling wordt pas betekenisvol nadat elke sessie een benoemde klasse heeft gekregen. Twee eenvoudige Direct Play-streams mogen niet hetzelfde worden gewogen als één 4K HDR-conversie met afbeeldingsondertiteling.

Het zwaarste normale pad bepaalt de eerste bovengrens

Gelijktijdigheid vermenigvuldigt alleen de resources die door elk pad worden gebruikt. Een Direct Play-stream voegt opslaglezingen en netwerklevering toe, terwijl een transcodering decoderingscapaciteit, filters, tonemapping, codering, tijdelijke opslag en CPU-capaciteit voor terugval kan verbruiken.

Meet de actieve resource met benutting en verzadiging in plaats van te vertrouwen op één GPU- of CPU-percentage. Er kan een wachtrij ontstaan wanneer één stap niet langer realtime kan worden bediend, zelfs als andere componenten nog ruimte over hebben.

De eerste herhaalbare wachtrij of het eerste verlies van buffermarge is de bruikbare bovengrens voor die werklast. Ongebruikte, snellere resources elders verhogen die niet.

Externe en gedeelde werklasten verschuiven de grens

Externe sessies hebben doorgaans een kleinere uploadcapaciteit en variabelere latentie dan lokale clients. Een gelijktijdige back-up, indexeerder of downloadtaak kan ook hetzelfde opslag- of netwerkpad gebruiken en de marge verkleinen tijdens precies de minuten waarop kijkers starten of vooruit- en terugspoelen.

Vergelijk lokale en externe scenario's met het model voor resources bij meerdere apps, terwijl media en clientbeleid gelijk blijven. Als alleen het externe scenario buffermarge verliest, ligt de grens bij het pad of de uploadcapaciteit en niet bij de media-engine.

Dezelfde server heeft daarom meerdere bovengrenzen: lokale Direct Play, lokale transcodering, externe levering en de piekbelasting van naast elkaar draaiende services.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Gebruik een herhaalbare capaciteitsdrempel

Een nuttige acceptatietest begint met de zwaarste verwachte sessie en voegt vervolgens één voor één normale gelijktijdige streams toe. Leg de opstarttijd, stabiele bufferstatus, weggevallen frames, wachtrijdiepte en de resource die als eerste verzadigd raakt vast.

Gebruik de koude en warme benchmark als stopregel: houd ruimte over zodra latentie, fouten of wachtrijen herhaaldelijk optreden, niet wanneer een dashboard slechts een hoge benutting weergeeft.

Stop wanneer de beoogde mix meerdere keren slaagt met stabiele weergave en een zichtbare marge. Zet het resultaat niet om in een universeel streamaantal voor andere media of clients.