Jellyfin bör ha tillräckligt med ledigt lagringsutrymme för den största normala kombinationen av metadataökning, genererade resurser, transkodningsfiler, loggar och underhållsarbete.
En fast procentsats är opålitlig eftersom ett enkelt bibliotek och ett bibliotek med mycket trickplay kan använda applagring på helt olika sätt. Separera varaktig tillväxt från tillfälliga toppar och mät sedan båda på de sökvägar där de faktiskt uppstår. Ledigt utrymme på en medievolym hjälper inte om konfigurations- eller transkodningslagringen ligger på ett annat fullt filsystem.
Mät tillväxten av beständiga appdata först
Databas, metadata, bilder, insticksprogram och genererade resurser kan växa när biblioteket och de aktiverade funktionerna utökas. Deras utveckling bör mätas separat från källmediernas kapacitet.
Genererade resurser kan öka arbetsmängden avsevärt; en Jellyfin-operatör undviker Trickplay och kapitelbilder eftersom de förbrukar extra lagringsutrymme och processorkraft under biblioteksuppdateringar.
Notera storleken på konfigurationskatalogen efter en avslutad genomsökning och sedan igen efter en representativ månad eller en stor import. Använd den uppmätta tillväxttakten i stället för att gissa utifrån medievolymer i terabyte.
Mät transkodningsutrymmet som en tillfällig topp
Aktiva konverteringar skapar arbetsfiler som kan försvinna när sessionen avslutas. Värsta fallet beror på den största källfilen, antalet samtidiga transkodningar och den konfigurerade tillfälliga sökvägen.
Genom att hålla transkodningsutrymmet på snabb lokal lagring separeras tillfälligt arbete med många skrivningar från bibliotekets beständiga data.
Kör de mest krävande samtidiga transkodningarna du förväntar dig och notera den maximala tillfälliga användningen. Reservera det utrymmet separat från budgeten för långsiktiga appdata.
Schemalagda jobb kan skapa kortvariga toppar
Trickplay, bildextrahering, genomsökningar och analys av insticksprogram kan förbruka processorkraft och lagringsutrymme samtidigt. Flera uppgifter som startar under samma tidsfönster kan skapa ett tillfälligt utrymmesbehov som är mycket större än den normala användningen i viloläge.
Bakgrundsarbete visas som schemalagda Jellyfin-uppgifter, så tester av ledigt utrymme bör omfatta de jobb som faktiskt genererar eller uppdaterar biblioteksdata.
Sprid ut tunga uppgifter och övervaka det lediga utrymmet under en hel schemalagd cykel. Rollkartan för medieservrar i hemmet hjälper till att förhindra att tillfälligt arbete i tysthet delar på en nästan full systemvolym.
Ställ in varningen ovanför felgränsen, inte vid noll
Om du väntar tills filsystemet når 100 % finns för lite utrymme kvar för databasskrivningar, paketuppdateringar, loggar och återställningsåtgärder. Varningen bör utlösas medan det fortfarande är säkert att rensa eller flytta data.
Obegränsade containerloggar kan förbruka lagringsutrymme på värdsystemet oberoende av programmets medier.
Välj en gräns för ledigt utrymme som ligger över den största uppmätta tillfälliga toppen plus den normala tillväxten. Beräkna om gränsen efter att du har aktiverat nya funktioner för genererat medieinnehåll eller ändrat transkodningskatalogen.
Support och tips
Mer att läsa

Bör du säkerhetskopiera Jellyfin medan tjänsten körs eller stoppa tjänsten först?
Föredra säkerhetskopior av stoppade tjänster för enkelhetens skull; använd live-ögonblicksbilder endast när applikationstillståndet fångas konsekvent och återställningar har testats.

Varför blir Jellyfin varmt eller högljutt när ingen streamar?
Värme vid inaktivitet beror vanligtvis på bakgrundsarbete eller en belastning från en delad värd, så identifiera den aktiva processen och den schemalagda uppgiften innan...

När bör du bygga om i stället för att reparera Jellyfin?
Välj ominstallation framför reparation när problemet är avvikelser i körmiljön och beständiga data är säkerhetskopierade; ”ominstallera” inte genom att radera den enda fungerande databasen.

