Moet je metagegevens van media op de SSD bewaren of bij de bibliotheek?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Should You Keep Media Metadata on SSD or With the Library? - Zima Store Online

Houd de database en actieve cache van de mediaserver op een SSD, en bewaar draagbare NFO-bestanden en geselecteerde illustraties bij de bibliotheek wanneer migratie belangrijk is.

‘Metadata’ omvat verschillende zaken: de applicatiedatabase, gebruikersstatus, indexen, caches, gedownloade illustraties, hoofdstukafbeeldingen, Trickplay-voorbeelden, NFO-sidecars en handmatig samengestelde afbeeldingen. Door alles op één locatie te plaatsen, ontstaat óf onnodige HDD-latentie óf beperkte draagbaarheid. Een thuis-mediaserver werkt doorgaans het best met een gesplitste indeling waarvan de grenzen voor back-up en herstel zijn gedocumenteerd.

Classificeer de metadata voordat je een schijf kiest

Breng de applicatiedatabase, configuratie, gebruikersaccounts, kijkgeschiedenis, indexen, caches, miniaturen, posters, achtergronden, NFO-bestanden, ondertitels en plug-ingegevens in kaart. Markeer elk item als gezaghebbend, draagbaar, opnieuw op te bouwen of tijdelijk.

De applicatiedatabase en gebruikersstatus zijn doorgaans serverspecifiek en veranderen vaak. NFO-bestanden en illustraties die naast media zijn opgeslagen, zijn bestandseigen begeleidende bestanden die door een andere compatibele bibliotheek kunnen worden gelezen, terwijl caches en gegenereerde miniaturen wegwerpbaar kunnen zijn.

Kies geen locatie uitsluitend op basis van de naam van de totale map. Een map met de naam ‘metadata’ kan zowel onvervangbare handmatige bewerkingen als eenvoudig opnieuw te genereren afbeeldingscaches bevatten. Daarom zijn voor de inhoud verschillende back-up- en plaatsingsregels nodig.

Plaats databases, indexen en actieve caches op een SSD

Databasequery's, bladeren door de bibliotheek, zoeken, updates van de gebruikersstatus en het opzoeken van miniaturen omvatten veel kleine lees- en schrijfbewerkingen. Een SSD verlaagt de latentie van deze bewerkingen en houdt ze weg van de sequentiële mediabelasting.

Snelle opslag is geen excuus voor een onveilig bestandssysteem of een te klein volume. Een Jellyfin-issue meldt databaseblokkeringen en een niet-reagerende interface tijdens normaal gebruik. Dit laat zien dat de applicatiedatabase een actieve operationele afhankelijkheid is, geen wegwerpbare cache.

Plaats de volledige persistente app-data-eenheid op een SSD met voldoende vrije ruimte, snapshots en back-ups. Plaats de actieve database niet op een netwerkshare, tenzij de applicatie expliciet ondersteuning biedt voor het vergrendelingsgedrag en de latentie daarvan.

Bewaar draagbare NFO-bestanden en samengestelde illustraties bij media wanneer dat nuttig is

Sidecar-NFO-bestanden, lokale posters, editi labels en handmatig geselecteerde illustraties kunnen het eenvoudiger maken om een bibliotheek in een andere instantie opnieuw op te bouwen. Ze blijven zichtbaar in de filmmap wanneer de applicatiedatabase verloren gaat.

Draagbaarheid is niet voor elke versie en scanner gegarandeerd. Een Jellyfin-migratierapport beschrijft dat bestaande NFO-bestanden na een verplaatsing werden genegeerd en overschreven. Daarom is een testimport vereist voordat je sidecars als enige herstelpad gebruikt.

Bewaar alleen metadata die de applicatie consistent kan lezen en die je wilt behouden. Maak een back-up van handmatig samengestelde bestanden en voorkom dat automatische providers ze zonder gecontroleerde test overschrijven.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Respecteer grenzen voor alleen-lezenbibliotheken en machtigingen

Een alleen-lezen-mediakoppeling beschermt bronbestanden tegen onbedoelde wijzigingen door de applicatie, maar voorkomt ook dat de server NFO-bestanden, illustraties, collecties en lokale voorbeelden naast de bibliotheek schrijft.

In een Jellyfin-issue mislukte het maken van een collectie doordat het mediabestandssysteem alleen-lezen was, hoewel de applicatieconfiguratie op de SSD wel beschrijfbaar was. Dit geval laat zien waarom de schrijflocatie invloed heeft op metadatafuncties.

Als onveranderlijkheid van de bron belangrijk is, houd media dan alleen-lezen en stuur app-eigen metadata naar het SSD-volume. Verleen schrijftoegang tot de bibliotheek alleen wanneer lokale sidecars bewust onderdeel zijn van het herstelplan, en beperk die toegang tot de service-identiteit.

Houd opnieuw op te bouwen voorbeeldgegevens gescheiden van kritieke status

Trickplay-afbeeldingen, hoofdstukminiaturen, geëxtraheerde voorbeeldrasters en tijdelijke caches kunnen veel groter worden dan de kerndatabase. Ze hebben ook een andere back-upwaarde, omdat ze vaak opnieuw kunnen worden gegenereerd.

Jellyfin biedt opties om illustraties en Trickplay-afbeeldingen naast media op te slaan, wat in sommige indelingen de zichtbaarheid en migratie verbetert. De broncode van de interface beschrijft de plaatsing van lokale illustraties en Trickplay als afzonderlijke keuzes, niet als één universele metadata locatie.

Gebruik een speciale cache of metadatasubvolume wanneer voorbeelden aanzienlijk groeien. Maak vaker een back-up van de database en handmatige metadata dan van opnieuw op te bouwen miniaturen, en documenteer welke mappen tijdens herstel mogen worden verwijderd.

Kies de indeling op basis van herstel- en migratiebehoeften

Gebruik uitsluitend SSD-opslag voor app-metadata wanneer één server de bibliotheek beheert, de mediamount alleen-lezen moet blijven en snel bladeren belangrijker is dan draagbaarheid op bestandsniveau. Gebruik lokale NFO-bestanden en illustraties wanneer samengestelde metadata met de bestanden moet meeverhuizen of wanneer meerdere compatibele tools de bibliotheek delen.

Een gesplitste indeling biedt doorgaans de beste grens: database, gebruikers, indexen en actieve caches op de SSD; bronmedia op opslag met hoge capaciteit; geselecteerde NFO-bestanden en samengestelde illustraties naast media; grote, opnieuw op te bouwen voorbeelden in een afzonderlijk gedimensioneerde cache of op een ondersteund lokaal pad.

Gegevenstype	Voorkeurslocatie	Back-upprioriteit
App-database, gebruikers, kijkstatus	SSD-appvolume	Hoog
Indexen en actieve cache	SSD of speciale cache	Laag tot gemiddeld
Samengestelde NFO en illustraties	Naast media wanneer draagbaarheid belangrijk is	Hoog indien handmatig bewerkt
Trickplay- en hoofdstukafbeeldingen	Gedimensioneerde cache of ondersteund lokaal pad	Doorgaans opnieuw op te bouwen
Bronfilms en series	Opslag met hoge capaciteit	Afhankelijk van vervangbaarheid

De ZimaSpace-gids over het kiezen van NAS-schijven voor app- en metadatabelastingen biedt de opslagprestatiecontext voor deze splitsing.

Controleer de indeling met back-up- en hersteltests

Stop de mediaserver en maak een back-up van het SSD-appvolume en alle sidecar-metadata die bij de bibliotheek is opgeslagen. Herstel deze naar een geïsoleerde instantie met dezelfde containerpaden en machtigingen.

Controleer of gebruikers, kijkgeschiedenis, collecties, handmatige overeenkomsten, illustraties en één item met ingeschakelde Trickplay zoals verwacht terugkomen. Test vervolgens een tweede herstel met alleen de mediabestanden en sidecars om vast te stellen wat verloren zou gaan zonder de app-database.

De indeling is correct wanneer bladeren responsief blijft, de app-opslag voorspelbaar groeit, media zo veel mogelijk alleen-lezen kan blijven en de gedocumenteerde back-up elk niet-opnieuw-opbouwbaar onderdeel herstelt. Wijzig de plaatsing pas nadat de hersteltest een echt probleem met snelheid, capaciteit of draagbaarheid aan het licht brengt.