Jellyfin-logboeken mogen nooit zo groot worden dat ze de database, cache of het besturingssysteem om de laatste vrije gigabytes laten concurreren. Voorkom dit door zowel de logdetails van Jellyfin zelf als de loglaag van de container of host te beperken, die dezelfde gebeurtenissen mogelijk opnieuw verzamelt.
Dit wordt het gemakkelijkst over het hoofd gezien op een klein systeemstation van een homeserver, omdat twee onafhankelijke logpaden tegelijk kunnen groeien: Jellyfin schrijft applicatielogboeken, terwijl Docker, journald of een andere supervisor stdout en stderr afzonderlijk kan bewaren. Begin met vaststellen welk pad daadwerkelijk schijfruimte inneemt, beperk de bewaartermijn op die laag, controleer het opruimen tijdens normaal gebruik en houd een waarschuwing voor vrije ruimte actief, zodat een toekomstige debug-sessie de schijf niet ongemerkt kan vullen.
Vind uit welke logopslag daadwerkelijk groeit
Meet voordat je iets verwijdert. Vergelijk de grootte van Jellyfins geconfigureerde logmap met de logopslag van de containerruntime of servicemanager, en let op welke daarvan verandert terwijl je een normale bibliotheekscan of afspeelsessie uitvoert. Als slechts één pad groeit, pak dan dat pad aan in plaats van meerdere rotatie-instellingen tegelijk te wijzigen.
In de probleemoplossingsgids van Jellyfin staat dat debuglogging een zeer grote hoeveelheid uitvoer kan genereren en bedoeld is voor korte probleemoplossingsvensters. Controleer daarom eerst of een aangepast logging.json uitgebreide categorieën ingeschakeld heeft gelaten. Bekijk de richtlijnen voor debuglogging voordat je bewaartermijnen wijzigt.
Als Jellyfins eigen logmap stabiel blijft maar de systeemschijf van de host kleiner blijft worden, controleer dan vervolgens de runtime-logboeken. Dat resultaat betekent dat het verwijderen van Jellyfin-logbestanden slechts het zichtbare symptoom behandelt, terwijl de tweede loglaag blijft groeien.
Stel een bewaarlimiet in op runtime-niveau
Kies voor containers een loggingstuurprogramma en rotatiebeleid met een vast maximum, in plaats van onbeperkte groei te gebruiken. Pas de instelling toe op nieuw aangemaakte containers en noteer het gekozen maximum, zodat een toekomstige herbouw van het compose-bestand de bescherming niet verwijdert.
Docker documenteert dat de standaardlogging met json-file aanzienlijk veel schijfruimte kan gebruiken wanneer rotatie niet is geconfigureerd, terwijl het stuurprogramma local standaard roteert. Gebruik dit rotatiegedrag voor containerlogboeken om te bepalen of je max-size/max-file begrenst of het lokale stuurprogramma gebruikt.
Maak de Jellyfin-container na het wijzigen van het runtimebeleid opnieuw aan als je runtime dat vereist en controleer of de actieve container daadwerkelijk het nieuwe stuurprogramma gebruikt. Een instelling op daemonniveau die alleen op nieuwe containers van toepassing is, vormt geen geslaagde oplossing totdat de Jellyfin-instantie deze heeft overgenomen.
Houd het opruimen van Jellyfin nuttig, maar zie het niet als enige bescherming
Jellyfin bevat onderhoudstaken die logboeken, cache, activiteitenlogboeken en transcodegegevens wissen, maar gepland opruimen is een tweede verdedigingslinie en geen reden om logging onbeperkt te laten groeien. Een taak kan mislukken, vertraagd worden uitgevoerd of pas starten nadat een piek de resterende systeemruimte al heeft opgebruikt.
Gebruik de taakgeschiedenis van het dashboard om te bevestigen dat de taak voor het opruimen van logboeken succesvol wordt uitgevoerd en vergelijk vervolgens de grootte van de logmap vóór en na de eerstvolgende geplande uitvoering. Als de map nooit kleiner wordt, onderzoek dan taakfouten of een onjuist pad in plaats van het schema blindweg te verkorten.
Een nuttig patroon voor een homeserver is om de applicatiestatus en mediaprocessen inzichtelijk te houden zonder dat diagnostische bestanden de opstartschijf domineren. Dezelfde resourcegerichte aanpak is nuttig bij het oplossen van buffering in Jellyfin, omdat logboeken alleen helpen wanneer ze naar het daadwerkelijke knelpunt wijzen.
Gebruik debuglogging als een diagnostische modus met tijdslimiet
Wanneer je debuguitvoer nodig hebt, bepaal dan vooraf de starttijd, het reproductievenster en de stopvoorwaarde. Leg de mislukte actie vast, bewaar het relevante loggedeelte op een veilige plek en zet de configuratie onmiddellijk nadat het bewijs is verzameld terug naar de normale uitvoerigheid.
Laat debuglogging niet dagenlang ingeschakeld alleen omdat er momenteel voldoende schijfruimte beschikbaar is. Een rustige avond en een bibliotheekscan kunnen zeer verschillende hoeveelheden loggegevens produceren, waardoor een instelling die tijdens één test onschuldig lijkt, tijdens gepland werk kostbaar kan worden.
Start na het terugzetten naar normale logging één keer opnieuw op als de configuratie dat vereist en voer een normale afspeelsessie plus één geplande taak uit. De groeisnelheid van de logboeken moet terugkeren naar het basisniveau. Als dat niet gebeurt, open je de configuratie opnieuw en controleer je of het verwachte bestand daadwerkelijk door Jellyfin is geladen.
Voeg een stopvoorwaarde voor vrije ruimte toe voordat de schijf kritiek vol raakt
Stel een eenvoudige waarschuwing in voor het bestandssysteem dat Jellyfin-gegevens, runtime-logboeken of het besturingssysteem bevat. De drempel moet voldoende ruimte overlaten om de oorzaak te onderzoeken en services veilig te stoppen, in plaats van te wachten totdat schrijfbewerkingen op de host beginnen te mislukken.
Als de vrije ruimte onverwacht afneemt, stop dan eerst de bron van de grote hoeveelheid loggegevens, bewaar een klein diagnostisch voorbeeld en verwijder alleen bekende wegwerpbare logboeken of caches. Begin niet met het verwijderen van Jellyfin-databases, configuratiebestanden of onbekende volume-inhoud om ruimte vrij te maken.
De preventie is voltooid wanneer normaal afspelen, een bibliotheektaak en een herstart niet langer onbeperkte groei veroorzaken en de waarschuwing comfortabel boven de activeringsdrempel blijft. Als de ruimte blijft afnemen terwijl logging begrensd is, breid het onderzoek dan uit met een algemene controle van het schijfgebruik, omdat niet langer bewezen is dat Jellyfin-logboeken de oorzaak zijn.
Ondersteuning & Tips
Meer om te lezen

Moet Jellyfin één gedeeld account of afzonderlijke huishoudaccounts gebruiken?
Kies Jellyfin-huishoudaccounts op basis van de identiteits-, toegangs-, ouderlijketoezichts- en herstelgrenzen die je nodig hebt.

Waarom blijft het geheugengebruik van Jellyfin hoog nadat het werk is voltooid?
Maak onderscheid tussen geheugengroei van het Jellyfin-proces en de Linux-cache, en onderzoek het alleen wanneer het geheugengebruik blijft stijgen of daadwerkelijk voor druk zorgt.

Signalen dat een Jellyfin-opslagindeling een herstelrisico begint te vormen
Controleer de opslagrollen van Jellyfin, scheid de actieve toestand van back-ups en opnieuw opbouwbare gegevens, en toon met een herstel aan dat de indeling...

