Varför använder Jellyfin mycket CPU efter en uppdatering?
Hög CPU-användning i Jellyfin efter en uppdatering beror vanligtvis på en av fyra saker: arbete vid uppstart eller med databasen, schemalagda biblioteksuppgifter, programvaru- eller partiell transkodning, eller ett plugin/programtillägg eller bakgrundsjobb vars beteende har ändrats i den nya versionen. Anta inte att uppdateringen permanent har gjort Jellyfin tyngre innan du har identifierat vilken process och uppgift som använder CPU:n.
Den snabbaste felsökningen är att jämföra tidpunkt och arbetsbelastning. Om CPU-användningen bara är hög i några minuter efter uppstart ska du kontrollera uppstarts- och aktivitetsloggarna. Om den ökar endast under uppspelning ska du granska den aktiva strömmen och FFmpeg-sökvägen. Om den förblir hög när ingen tittar ska du kontrollera schemalagda uppgifter och plugin-program. Ändra en variabel i taget och återskapa sedan samma situation, så att du kan skilja ett tillfälligt jobb efter uppdateringen från en varaktig regression.
Skilj uppstartsarbete från CPU-användning i normalt driftläge
Starta om Jellyfin en gång under en lugn period och notera hur länge CPU-användningen förblir hög. Följ serverloggen efter meddelanden om migrering, databasoptimering, inläsning av plugin-program eller biblioteksrelaterade åtgärder. Vänta sedan tills webbgränssnittet och de schemalagda uppgifterna har stabiliserats innan du bedömer den nya normalnivån.
Jellyfins schemalagda uppgifter och uppgifter vid uppstart omfattar bland annat biblioteksskanningar, extrahering av nyckelbildrutor, databasoptimering, rensning av cache och uppdateringar av plugin-program. Vissa uppgifter körs också vid uppstart, så en topp efter uppdateringen kan vara underhållsarbete och inte en permanent prestandaförändring.
Om CPU-användningen återgår till det tidigare inaktiva intervallet när uppgifterna är klara ska du inte justera transkodningen eller byta maskinvara. Då har din felsökning redan visat att det rör sig om tillfälligt bakgrundsarbete. Schemalägg i stället tunga uppgifter utanför tittartiderna om de stör uppspelningen.
Kontrollera om uppspelningen nu använder CPU:n
Om CPU-toppen börjar först när en viss klient startar uppspelning ska du öppna Jellyfin-instrumentpanelen och fastställa om sessionen använder Direct Play, ommuxning, ljudtranskodning eller videotranskodning. En ändring av klient eller codec kan aktivera en programvarusökväg som inte användes tidigare.
Tvinga fram uppspelning av samma media på samma klient med undertexter avstängda och jämför sedan CPU-användningen. Om användningen sjunker kraftigt är undertext- eller transkodningssökvägen den avgörande skillnaden. Om den förblir hög under Direct Play ska du undersöka lagring, plugin-program eller en annan process i stället för att skylla på kodaren.
För en djupare kontroll av uppspelningen använder du samma metod som beskrivs i kontrollen av maskinvarutranskodning: verifiera den aktiva GPU-/FFmpeg-sökvägen i stället för att bara lita på att maskinvaruacceleration är aktiverad i inställningarna.
Mät containerprocessen i stället för att gissa utifrån värdmaskinens belastning
På en delad hemmaserver ska du kontrollera att Jellyfin faktiskt är processen som använder CPU:n. Säkerhetskopieringar, mediaindexerare, nedladdningsklienter, generering av miniatyrbilder och filsystemunderhåll kan ha startats kring samma omstart eller uppdatering.
Containerkörmiljöer erbjuder vyer över användningen per container. Dockers kommandot stats är utformat för att visa resursanvändning i realtid för körande containrar. Använd resursanvändning per container eller motsvarande funktion på din plattform medan du återskapar problemet.
Om en annan container använder CPU:n ska du pausa det jobbet och upprepa det ursprungliga testet. Om Jellyfin använder den ska du fortsätta undersöka Jellyfins uppgifter och uppspelning. Om inte var uppdateringen endast tidsmässigt sammanfallande med belastningen på värdmaskinen och inte orsaken.
Inaktivera eller schemalägg om en bakgrundskälla i taget
Kontrollera Jellyfins sida för schemalagda uppgifter och se om någon uppgift körs just nu eller startar om upprepade gånger. Granska också plugin-program som lägger till egna schemalagda jobb, metadataförespråkare, identifiering av introsekvenser, undertextbearbetning eller annan biblioteksautomatisering.
Inaktivera inte alla plugin-program och uppgifter permanent i ett enda steg. Pausa en misstänkt högkostnadskandidat, låt CPU-användningen stabiliseras och återskapa sedan samma inaktiva läge eller skanningsförhållande. En tydlig minskning identifierar grenen. Om inget ändras återställer du den och testar nästa kandidat.
Om uppgiften är legitim men olämpligt schemalagd ska du schemalägga om den i stället för att behandla den som ett fel. Om den loopar, misslyckas eller startar om direkt efter uppdateringen ska du spara loggar och information om plugin- och versionsnummer innan du ändrar databasfiler eller bygger om servern.
Bekräfta lösningen under den ursprungliga belastningen efter uppdateringen
När du har identifierat orsaken tillämpar du rätt åtgärd: låt migreringarna slutföras, schemalägg om en uppgift, återställ maskinvaruacceleration, uppdatera eller inaktivera ett problematiskt plugin-program eller korrigera klient-/transkodningsförhållandet. Starta sedan om en gång och upprepa exakt det test som tidigare drev upp CPU-användningen.
En lyckad åtgärd innebär att CPU-beteendet återigen motsvarar arbetsbelastningen: inaktivitet stabiliseras efter uppstart, Direct Play förblir resurssnålt och eventuell nödvändig transkodning använder den förväntade accelerationssökvägen. En lugn minut utan att utlösaren upprepas räcker inte.
Gå vidare med mer omfattande felsökning när CPU-användningen förblir hög utan aktiva uppgifter, utan transkodning, utan en konkurrerande container och med en ren plugin-baslinje. Samla då in Jellyfin-versionen, operativsystem/arkitektur, uppgifternas status och ett kort loggfönster, så att en versionsspecifik regression kan undersökas utan att man drar slutsatser från en enda upptagen uppstart.
Rekommenderade produkter
Support och tips
Mer att läsa
Jellyfin fungerar via Wi-Fi men inte via Ethernet eller VPN
När Jellyfin bara fungerar via Wi‑Fi ska du isolera den förändrade nätverkssökvägen: destination, routing, brandväggens/lokal klassificering och därefter VPN-överlappning.
Så avvecklar du Jellyfin utan att lämna oskyddade data kvar
Avveckla Jellyfin säkert genom att bevara en sista återställningspunkt, stänga åtkomstvägar och redovisa varje volym, monteringspunkt, säkerhetskopia och inloggningsuppgift.
Bör du använda automatiska uppdateringar för Jellyfin på en hemmaserver?
Automatiska Jellyfin-uppdateringar är säkrast när säkerhetskopiering, versionsomfattning, återställning och validering efter uppdateringen är definierade innan den obevakade övergången.
