Varför fyller generering av miniatyrbilder en mediaservers app-lagring?
Generering av miniatyrbilder fyller appens lagringsutrymme eftersom servern skapar många härledda bilder och lagrar dem i en skrivbar metadata- eller cachesökväg.
Ett mediebibliotek kan lagra videor på flera terabyte i en HDD-pool medan dess container kopplar konfiguration, metadata och cache till en betydligt mindre SSD- eller startvolym. Kapitelbilder, trickplay-förhandsvisningar, affischer, bakgrunder och temporära extraheringsfiler växer sedan i takt med bibliotekets användning och genereringsinställningarna, inte enbart med källfilernas storlek. Den säkra lösningen börjar med att identifiera den exakta typen av härledd fil och sökvägen innan du tar bort något som databasen fortfarande förväntar sig.
Hitta katalogen som faktiskt växer
Mät medieprogrammets konfigurations-, cache-, metadata-, omkodnings- och temporära kataloger separat. Sortera underkatalogerna efter allokerad storlek och senaste ändringstid medan en miniatyrbildsuppgift körs.
Extrahering av kapitelbilder beskrivs uttryckligen i Jellyfins gränssnittstexter som långsam, resurskrävande och potentiellt något som kräver flera gigabyte utrymme.
Bekräfta om tillväxten sker i värddatorns bind-mount, en namngiven volym eller containerns skrivbara lager. Om containerlagret växer ska du åtgärda beständigheten innan du rensar; annars kan utrymmet försvinna från appens vy samtidigt som det fortfarande förbrukar Dockers systemlagring.
Identifiera vilken bildfunktion som skapade filerna
Skilj vanliga affischer och bakgrunder från kapitelbilder, trickplay-förhandsvisningar, videoförhandsvisningar, intro-markörer och plugin-genererade bilder. Varje funktion har olika utlösare och regler för lagringstid.
Trickplay skapar upprepade visuella samplar längs en videotidslinje så att klienter kan visa förhandsvisningar när användaren söker i videon. De resulterande bildrutnäten skalas främst med den totala speltiden, samplingsintervallet, upplösningen, kvaliteten och rutnätslayouten, snarare än med om källan är i 1080p eller 4K.
Kör en schemalagd uppgift manuellt medan du övervakar målkatalogen. Matcha nya filnamn och databasposter med funktionen som skapade dem. Inaktivera inte alla metadataleverantörer när det bara är en enskild förhandsvisningsuppgift som orsakar problemet.
Kontrollera intervall, upplösning, kvalitet och biblioteksomfattning
Notera miniatyrbildens bredd, samplingsintervallet, JPEG- eller WebP-kvaliteten, rutdimensionerna, antalet trådar och vilka bibliotek som ingår i genereringen. Kortare intervall och större bilder skapar fler lagrade pixlar per videotimme.
Genereringen kan också starta om efter en inställningsändring eller uppgradering. Ett Jellyfin-ärende beskriver användare som inte kunde hindra tidigare genererade trickplay-data från att återkomma eftersom inaktivering av funktionen inte rensade befintliga resultat.
Ändra en inställning i ett litet testbibliotek och jämför antalet genererade byte per medietimme. Använd den uppmätta kvoten för att uppskatta hela biblioteket innan du startar ännu en fullständig extraheringsuppgift.
| Inställningsändring | Sannolik lagringseffekt | Kompromiss |
|---|---|---|
| Längre samplingsintervall | Färre bilder | Mindre exakta förhandsvisningar vid sökning |
| Mindre miniatyrbredd | Mindre filer | Mjukare förhandsvisningsbilder på TV |
| Lägre bildkvalitet | Mindre filer | Fler komprimeringsartefakter |
| Smalare biblioteksomfattning | Mindre total lagring | Inga förhandsvisningar för exkluderade bibliotek |
Välj inställningar som passar de faktiska klienternas skärmar och sökbeteende i stället för att generera härledda filer i högsta kvalitet för varje titel.
Leta efter gamla eller övergivna uppsättningar med miniatyrbilder
Jämför aktiva medieobjekt med genererade kataloger efter att filer har ersatts, bytt namn, flyttats eller tagits bort. Gamla uppsättningar med förhandsvisningar kan finnas kvar när den nya filen får ett annat objekt-ID eller ett annat utdatafilnamn.
En Jellyfin-rapport visar att gamla trickplay-bilder som lagrats bredvid medier inte togs bort när nya förhandsvisningar genererades, vilket lämnade föråldrade trickplay-data bredvid den aktuella uppsättningen.
Använd först programmets stödda rensningsuppgift och kontrollera att du har en säkerhetskopia av metadatadatabasen. Om manuell borttagning är nödvändig ska du testa med ett övergivet objekt och uppdatera det innan du tar bort stora katalogträd vars referenser är okända.
Kontrollera om bilderna hör hemma i appens lagring eller bredvid medierna
Vissa medieservrar kan spara bilder eller trickplay-data bredvid biblioteket, medan andra lagrar databasbundna härledda filer i appens metadata. Om platsen flyttas påverkas säkerhetskopiering, behörigheter, migrering och beteendet hos skrivskyddade medier.
Att spara förhandsvisningar bredvid medierna kan göra migreringen enklare, men det kan också mångdubbla antalet små filer på en stor HDD-delning och kräva skrivåtkomst till biblioteket. Ett Jellyfin-migreringsärende visar att lokalt lagrade trickplay-filer kanske inte överförs korrekt mellan instanser.
Behåll databasbundna och ofta ändrade härledda filer på en appvolym med avsiktligt tilltagen storlek, såvida inte programmet har fullständigt stöd för portabla lokala bilder. Håll mediedelningen skrivskyddad när skrivåtkomst inte krävs för den valda layouten.
Flytta appvolymen utan att dela upp databastillståndet
Om inställningarna är rimliga men appvolymen är för liten ska du stoppa medieservern och flytta hela konfigurations-, metadata- och cacheenheterna enligt containerns design för beständiga mountar. Bevara ägarskap, ACL:er, databasfiler och symboliska länkar.
Artikeln från ZimaSpace om SSD-appvolymer för metadata och miniatyrbilder förklarar varför dessa arbetsbelastningar med små filer gynnas av snabb lagring, medan stora källmedier kan ligga kvar på hårddiskar.
Flytta inte bara den största bildkatalogen och lämna databassökvägarna kvar, såvida inte programmet stöder en sådan uppdelning. Starta den migrerade instansen isolerat och bekräfta att gamla miniatyrbilder kan öppnas innan du genererar nya.
Rensa säkert och skapa en tillväxtbaslinje
Pausa miniatyrbildsuppgifter, säkerhetskopiera appens databas och dokumentera det aktuella antalet filer och antalet byte per typ av härledd fil. Ta endast bort bekräftat gamla resultat eller använd programmets stödda funktioner för borttagning och regenerering.
En full SSD kan påverka mer än miniatyrbilder. Ett Jellyfin-ärende kopplar en full SSD till misstänkta databasskador och en ofullständig biblioteksvy, vilket visar varför slut på ledigt utrymme kan hota appens tillstånd.
Efter rensningen ska du köra genereringen för ett bibliotek, mäta den dagliga tillväxten och konfigurera varningar innan appvolymen når sin reservgräns. Åtgärden är klar när förväntade förhandsvisningar fungerar, gamla data inte längre återkommer och lagringstillväxten motsvarar det valda intervallet, upplösningen, kvaliteten och biblioteksomfattningen.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
