Bör du behålla mediametadata på SSD:n eller tillsammans med biblioteket?
Håll medieserverns databas och aktiva cache på SSD, och lagra portabla NFO-filer och utvalda bilder tillsammans med biblioteket när migrering är viktigt.
”Metadata” omfattar flera olika saker: applikationsdatabasen, användartillstånd, index, cache, nedladdade bilder, kapitelbilder, trickplay-förhandsvisningar, NFO-sidofiler och manuellt utvalda bilder. Om allt placeras på samma ställe uppstår antingen onödig fördröjning på hårddisken eller bristande portabilitet. En hemmaserver för media fungerar vanligtvis bäst med en uppdelad layout där gränserna för säkerhetskopiering och återställning är dokumenterade.
Klassificera metadata innan du väljer lagringsenhet
Inventera applikationsdatabasen, konfigurationen, användarkontona, visningshistoriken, indexen, cacheminnet, miniatyrbilderna, affischerna, bakgrundsbilderna, NFO-filerna, undertexterna och plugin-data. Märk varje objekt som auktoritativt, portabelt, återskapningsbart eller temporärt.
Applikationsdatabasen och användartillståndet är vanligtvis serverspecifika och ändras ofta. NFO-filer och bilder som lagras bredvid mediefilerna är filbaserade följeslagare som kan läsas av ett annat kompatibelt bibliotek, medan cache och genererade miniatyrbilder kan vara möjliga att radera.
Välj inte plats utifrån det övergripande mappnamnet. En katalog som kallas ”metadata” kan innehålla både oersättliga manuella redigeringar och enkelt återskapningsbara bildcachefiler, så innehållet behöver olika regler för säkerhetskopiering och placering.
Placera databaser, index och aktiva cachefiler på SSD
Databasfrågor, bläddring i biblioteket, sökning, uppdateringar av användartillstånd och uppslagning av miniatyrbilder innebär många små läsningar och skrivningar. En SSD minskar fördröjningen vid dessa åtgärder och håller dem åtskilda från den sekventiella mediebelastningen.
Snabb lagring ursäktar inte ett osäkert filsystem eller en underdimensionerad volym. Ett Jellyfin-ärende rapporterar databaslåsningar och ett gränssnitt som inte svarar under normal användning, vilket visar att applikationsdatabasen är ett aktivt operativt beroende, inte en förbrukningsbar cache.
Placera hela den beständiga appdataenheten på en SSD med tillräckligt ledigt utrymme, ögonblicksbilder och säkerhetskopior. Undvik att placera den aktiva databasen på en nätverksresurs om inte applikationen uttryckligen stöder dess låsning och fördröjningsbeteende.
Behåll portabla NFO-filer och utvalda bilder tillsammans med mediefilerna när det är lämpligt
NFO-sidofiler, lokala affischer, utgåveetiketter och manuellt utvalda bilder kan göra ett bibliotek enklare att återskapa i en annan instans. De finns kvar synliga i filmappen när applikationsdatabasen går förlorad.
Portabilitet garanteras inte mellan alla versioner och skannrar. En Jellyfin-rapport om migrering beskriver hur befintliga NFO-filer ignorerades och skrevs över efter en flytt, så en testimport krävs innan du förlitar dig på sidofiler som den enda återställningsvägen.
Lagra endast metadata som applikationen kan läsa konsekvent och som du avser att bevara. Behåll en säkerhetskopia av manuellt utvalda filer och förhindra att automatiska leverantörer skriver över dem utan ett kontrollerat test.
Respektera gränserna för skrivskyddade bibliotek och behörigheter
En skrivskyddad medieanslutning skyddar källfiler från oavsiktliga ändringar i applikationen, men hindrar också servern från att skriva NFO-filer, bilder, samlingar och lokala förhandsvisningar bredvid biblioteket.
I ett Jellyfin-ärende misslyckades skapandet av en samling med ett skrivskyddat mediefilsystem, trots att applikationskonfigurationen var skrivbar på SSD. Fallet visar varför skrivplatsen påverkar metadatafunktionerna.
Om källfilernas oföränderlighet är viktig ska du behålla mediefilerna skrivskyddade och styra appägd metadata till dess SSD-volym. Ge biblioteket skrivåtkomst endast när lokala sidofiler är en avsiktlig del av återställningsplanen, och begränsa åtkomsten till tjänstens identitet.
Håll återskapningsbara förhandsvisningsdata åtskilda från kritiskt tillstånd
Trickplay-bilder, kapitelminiatyrer, extraherade förhandsvisningsrutor och temporär cache kan bli mycket större än kärndatabasen. De har också ett annat säkerhetskopieringsvärde eftersom de ofta kan återskapas.
Jellyfin erbjuder alternativ för att spara bilder och trickplay-bilder bredvid mediefilerna, vilket förbättrar synlighet och migrering i vissa layouter. Källtexten för gränssnittet beskriver placering av lokala bilder och trickplay-bilder som separata val snarare än en enda universell metadataplats.
Använd en särskild cache- eller metadatavolym när förhandsvisningarna växer kraftigt. Säkerhetskopiera databasen och manuella metadata oftare än återskapningsbara miniatyrbilder, och dokumentera vilka mappar som kan raderas vid återställning.
Välj layout utifrån behov av återställning och migrering
Använd endast SSD för appmetadata när en server äger biblioteket, medieanslutningen bör förbli skrivskyddad och snabb bläddring är viktigare än filbaserad portabilitet. Använd lokala NFO-filer och bilder när utvalda metadata måste följa med filerna eller när flera kompatibla verktyg delar biblioteket.
En uppdelad layout ger vanligtvis den bästa avgränsningen: databas, användare, index och aktiva cachefiler på SSD; källmedier på lagring med hög kapacitet; utvalda NFO-filer och bilder bredvid mediefilerna; stora återskapningsbara förhandsvisningar på en separat dimensionerad cache eller en stödd lokal sökväg.
| Datatyp | Föredragen plats | Prioritet för säkerhetskopiering |
|---|---|---|
| Appdatabas, användare, visningstillstånd | SSD-volym för appar | Hög |
| Index och aktiv cache | SSD eller särskild cache | Låg till medelhög |
| Utvalda NFO-filer och bilder | Bredvid mediefilerna när portabilitet är viktig | Hög om de har redigerats manuellt |
| Trickplay- och kapitelbilder | Dimensionerad cache eller stödd lokal sökväg | Vanligtvis återskapningsbara |
| Källfilmer och serier | Lagring med hög kapacitet | Baserad på möjligheten att ersätta dem |
ZimaSpace-guiden om val av NAS-enheter för app- och metadatasbelastningar ger lagrings- och prestandakontexten för denna uppdelning.
Verifiera layouten med tester av säkerhetskopiering och återställning
Stoppa medieservern och säkerhetskopiera SSD-volymen för appar samt all sidofilmetadata som lagras tillsammans med biblioteket. Återställ dem i en isolerad instans med samma containersökvägar och behörigheter.
Bekräfta att användare, visningshistorik, samlingar, manuella matchningar, bilder och ett objekt med aktiverad trickplay-funktion återkommer som förväntat. Testa sedan en andra återställning med endast mediefilerna och sidofilerna för att se vad som skulle gå förlorat utan appdatabasen.
Layouten är korrekt när bläddringen förblir responsiv, appens lagringstillväxt är förutsägbar, mediefilerna kan förbli skrivskyddade enligt avsikt och den dokumenterade säkerhetskopian återskapar alla delar som inte kan byggas om. Ändra placeringen först när återställningstestet visar ett verkligt problem med hastighet, kapacitet eller portabilitet.
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.
