Waarom gebruikt Jellyfin na een update zoveel CPU?

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.

Een hoge Jellyfin-CPU-belasting na een update komt meestal door een van vier oorzaken: opstart- of databasewerk, geplande bibliotheektaken, softwarematige of gedeeltelijke transcoding, of een plug-in/achtergrondtaak waarvan het gedrag door de nieuwe versie is veranderd. Ga er niet van uit dat de update Jellyfin blijvend zwaarder heeft gemaakt voordat je hebt vastgesteld welk proces en welke taak de CPU gebruiken.

De snelste diagnose is het vergelijken van timing en belasting. Als de CPU alleen enkele minuten na het opstarten hoog is, bekijk dan de opstart- en taaklogboeken. Als de belasting alleen tijdens het afspelen stijgt, controleer dan de actieve stream en het FFmpeg-pad. Als de CPU hoog blijft terwijl niemand kijkt, controleer dan geplande taken en plug-ins. Wijzig steeds één variabele tegelijk en herhaal daarna dezelfde situatie, zodat je een tijdelijke taak na de update kunt onderscheiden van een blijvende regressie.

Maak onderscheid tussen opstartwerk en stabiele CPU-belasting

Start Jellyfin één keer opnieuw op tijdens een rustige periode en noteer hoelang de CPU-belasting verhoogd blijft. Let in het serverlogboek op meldingen over migratie, databaseoptimalisatie, het laden van plug-ins of bibliotheekgerelateerde activiteiten. Wacht vervolgens totdat de webinterface en geplande taken tot rust zijn gekomen voordat je de nieuwe basisbelasting beoordeelt.

De standaard geplande en opstarttaken van Jellyfin omvatten bibliotheeks scans, extractie van keyframes, databaseoptimalisatie, het opschonen van de cache en updates van plug-ins. Sommige taken worden ook bij het opstarten uitgevoerd, waardoor een piek na een update onderhoudswerk kan zijn en geen voortdurende prestatieverandering.

Als de CPU na het voltooien van de taken terugkeert naar het oude niveau bij inactiviteit, hoef je transcoding niet aan te passen of hardware te vervangen. Je situatie blijkt dan al te zijn teruggekeerd naar de normale toestand; plan zware taken in plaats daarvan buiten de kijkuren als ze het afspelen verstoren.

Controleer of afspelen nu de CPU gebruikt

Als de CPU-piek alleen begint wanneer een bepaalde client het afspelen start, open je het Jellyfin-dashboard en bepaal je of de sessie Direct Play, remuxing, audiotranscoding of videotranscoding gebruikt. Een wijziging in de client of codec kan een softwarepad activeren dat eerder niet werd gebruikt.

Forceer hetzelfde mediabestand op dezelfde client met ondertiteling uitgeschakeld en vergelijk daarna de CPU-belasting. Als het gebruik sterk daalt, is het ondertitelings- of transcodepad de onderscheidende factor. Blijft de belasting hoog tijdens Direct Play, kijk dan naar opslag, plug-ins of een ander proces in plaats van de encoder de schuld te geven.

Gebruik voor een grondigere controle van het afspelen dezelfde methode als beschreven bij het controleren van hardwaretranscoding: controleer het actieve GPU-/FFmpeg-pad in plaats van er alleen op te vertrouwen dat hardwareversnelling in de instellingen is ingeschakeld.

Meet het containerproces in plaats van te gokken op basis van de hostbelasting

Controleer op een gedeelde homeserver of Jellyfin daadwerkelijk het proces is dat de CPU gebruikt. Back-ups, media-indexers, downloadclients, thumbnailgeneratoren en bestandssysteemonderhoud kunnen rond dezelfde herstart of update zijn gestart.

Container-runtimes bieden weergaven van het gebruik per container; de Docker-opdracht stats is bedoeld om live resourcegebruik van actieve containers te tonen. Gebruik resourcegebruik per container of het equivalent van je platform terwijl je het probleem reproduceert.

Als een andere container de CPU gebruikt, pauzeer die taak dan en herhaal de oorspronkelijke test. Als Jellyfin de CPU gebruikt, ga dan verder met het controleren van Jellyfin-taken en het afspelen. Zo niet, dan viel de update alleen samen met de hostbelasting en was deze niet de oorzaak.

Schakel steeds één bron van achtergrondactiviteit uit of plan deze opnieuw

Controleer de pagina met geplande taken van Jellyfin op een taak die momenteel wordt uitgevoerd of steeds opnieuw wordt gestart. Bekijk ook plug-ins die eigen geplande taken, metadataleveranciers, introdetectie, ondertitelverwerking of andere bibliotheekautomatisering toevoegen.

Schakel niet in één stap alle plug-ins en taken permanent uit. Pauzeer één verdachte taak met hoge belasting, laat de CPU tot rust komen en reproduceer daarna dezelfde situatie bij inactiviteit of tijdens een scan. Een duidelijke daling wijst de oorzaak aan; verandert er niets, zet de taak dan terug en test de volgende kandidaat.

Als de taak legitiem maar slecht getimed is, plan deze dan opnieuw in plaats van hem als een defect te behandelen. Als de taak na de update blijft hangen, mislukt of onmiddellijk opnieuw start, bewaar dan de logboeken en informatie over plug-in en versie voordat je databasebestanden wijzigt of de server opnieuw opbouwt.

Bevestig de oplossing onder dezelfde belasting als na de update

Pas na het vaststellen van de oorzaak de passende oplossing toe: laat migraties voltooien, plan een taak opnieuw in, herstel hardwareversnelling, werk een problematische plug-in bij of schakel deze uit, of corrigeer de client-/transcodeconditie. Start daarna één keer opnieuw op en herhaal exact de test waardoor de CPU eerder hoog opliep.

Een geslaagde oplossing betekent dat het CPU-gedrag weer bij de belasting past: bij inactiviteit daalt de belasting na het opstarten, Direct Play blijft licht en noodzakelijke transcoding gebruikt het verwachte versnellingspad. Eén rustige minuut zonder de aanleiding opnieuw te activeren is niet voldoende.

Onderzoek het verder wanneer de CPU-belasting hoog blijft zonder actieve taken, transcoding, concurrerende container en met een schone plug-inbasis. Leg dan de Jellyfin-versie, het besturingssysteem/de architectuur, de taakstatus en een kort tijdsvenster uit het logboek vast, zodat een versiespecifieke regressie kan worden onderzocht zonder conclusies te trekken uit één druk opstartmoment.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.