Jellyfin har ingen tillförlitlig fast procentsats för extra utrymme, eftersom metadata, bildmaterial, cache, index och tillfälliga omkodningar skalar på olika sätt jämfört med källmediet.
Två bibliotek med samma mediestorlek kan kräva mycket olika mängder utrymme för programdata när antalet objekt, mängden bildmaterial, förhandsvisningar, genomsökningar eller användaraktivitet skiljer sig åt. Mät datakatalogen och de tillfälliga sökvägarna separat. Målet är en kapacitetsbudget baserad på tillväxt och toppbelastning, inte en universell regel på 5 %.
Beständiga programdata är en separat kapacitetspool
Databasen, metadata, bildmaterial, loggar och genererade index används vid bläddring, genomsökningar och uppdateringar av uppspelningsstatus. De bör mätas separat från filmerna och avsnitten som de beskriver.
Modellen för lagringskostnader skiljer programdatakapacitet från kapacitet för mediebulk och förklarar varför de växer enligt olika kurvor.
Ett stort mediearkiv kan ha måttliga mängder metadata, medan ett mindre bibliotek med omfattande bildmaterial eller förhandsvisningar kan förbruka mer programutrymme.
Funktionsinställningar påverkar utrymmesbehovet
Mängden bildmaterial, miniatyrer för förhandsvisning, analysdata, antalet objekt, insticksprogram och cachebeteende kan öka den beständiga lagringsanvändningen. Tillfällig omkodning fungerar annorlunda: den skapar ett maximalt arbetsutrymmesbehov under aktiva konverteringar.
Använd lagringslatens och genomströmning för att skilja mellan latens, genomströmning och tillfälligt arbetsutrymme när du dimensionerar lagringsvägen.
Beständig tillväxt hör hemma i programdatabudgeten; tillfälliga toppar hör hemma i utrymmesbudgeten för arbetsfiler.
Varför procentregler inte fungerar
Ett fast förhållande fungerar inte när biblioteket innehåller många små objekt, när förhandsvisningar är aktiverade eller när samtidiga konverteringar skapar ovanligt stora tillfälliga segment. Det kan också överskatta ett enkelt bibliotek med minimalt antal genererade resurser.
Jämförelsen i modellen för lagringskostnader visar varför den uppmätta aktuella storleken och tillväxttakten är mer användbara än en enda procentsats.
Gränsen förändras när en funktion eller arbetsbelastning ändrar datakurvan; gör en ny beräkning efter sådana förändringar.
Bygg budgeten utifrån mätningar
Notera aktuell storlek på programdata, månatlig tillväxt, den största toppen för tillfällig omkodning och en reserv för säkerhetskopior. Håll reserven för säkerhetskopior utanför den aktiva datakatalogen så att återställningsutrymme inte kan förbrukas av normal drift.
Använd mönstret för lagringskostnadsmodellen och uppdatera det efter genomsökningar, ändringar i analysen eller en större utökning av biblioteket.
Sluta lägga till kapacitet när den uppmätta beständiga tillväxten och de tillfälliga topparna båda ryms inom den valda marginalen för ledigt utrymme.
Teknik- och AI-hubb
Mer att läsa

Varför förändras Home Assistant-arkitekturen när en hemmaserver får fler tjänster?
Fler tjänster förändrar Home Assistants arkitektur när de lägger till delat tillstånd, köer, enheter, uppdateringscykler eller felområden – inte bara fler containrar.

Så mäter du prestandan hos Home Assistant utan att förväxla cache med kapacitet
Ett varmt resultat visar återanvändning, inte kapacitet. Mät kallstart, varm steady state, upprepad belastning, svanslatens och vilken resurs som först når sin kapacitetsgräns.

Hur mycket samtidighet för automatiseringar behöver Home Assistant för styrning av hela hemmet?
De flesta automatiseringar för hela hemmet behöver endast begränsad överlappning; dimensionera samtidigheten utifrån körningstid × utlösningsfrekvens och begränsa den sedan till en kapacitet som...

