Jellyfin startar men dess bakgrundsprocesser förblir offline

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Jellyfin Starts but Its Background Workers Remain Offline - Zima Store Online

Jellyfin tillhandahåller ingen universell bakgrundstjänst för arbeten som måste vara online separat från webbservern. Om gränssnittet läses in men ”workers” verkar vara offline ska du översätta symptomet till den specifika bakgrundsoperation som har fastnat: en biblioteksskanning, metadatauppdatering, uppgift för kapitelbilder, plugin-jobb eller någon annan schemalagd uppgift.

Den skillnaden är viktig eftersom en fungerande HTTP-slutpunkt endast bevisar att huvudserverprocessen har startat. Nästa steg är att identifiera ett jobb som borde köras, kontrollera dess senaste resultat och motsvarande loggrader och sedan följa den första felande beroendekomponenten—databas, skrivbar appdata, medielagring, plugin eller en resurs som är specifik för uppgiften—utan att bygga om en server som redan visar gränssnittet.

Identifiera den exakta bakgrundsuppgift som inte fortskrider

Öppna instrumentpanelen och välj en schemalagd uppgift vars beteende du kan observera. Notera när den kördes senast, när den ska köras nästa gång, dess aktuella status och om något förändras när du startar den manuellt. Gruppera inte alla inaktiva schemalagda uppgifter under ett enda symptom som ”worker offline”.

Jellyfins källkod dokumenterar en särskild ScheduledTasks-implementation på serversidan, vilket bekräftar att bakgrundsunderhåll hanteras som individuella schemalagda åtgärder snarare än som en generisk andra daemon. Jellyfins implementation av ScheduledTasks

Om en uppgift misslyckas medan andra slutförs ska du hålla felsökningen specifik för den uppgiften. Om ingen uppgift går att starta ska du leta efter ett gemensamt beroende, till exempel databastatus, behörigheter för datakatalogen eller en migrering vid uppstart, innan du ändrar enskilda biblioteksinställningar.

Läs det första relevanta felet, inte den sista felkaskaden

Använd Jellyfin-loggarna från tiden då uppgiften utlöstes. Sök efter uppgiftens namn och gå sedan uppåt till den första varningen eller det första felet som förklarar varför den inte kunde få ett databaslås, öppna en sökväg, skriva appdata, starta FFmpeg eller läsa in ett plugin-beroende.

Jellyfins felsökningsguide rekommenderar loggar som första plats för att diagnostisera server- och uppspelningsproblem och påpekar att felsökningsloggning kan skapa mycket stora mängder data. Jellyfins vägledning om loggning

Aktivera felsökningsloggning endast när de normala loggarna inte visar den relevanta delen, återskapa ett enda försök att köra uppgiften och återställ sedan loggningen till normal nivå. En kontrollerad återskapning är mer användbar än att låta felsökningsloggning vara aktiverad medan flera orelaterade schemalagda jobb skapar brus.

Kontrollera att datakatalogen kan skrivas till och att databasen kan fortsätta

Ett webbgränssnitt kan visas även när en senare bakgrundsoperation inte kan skriva till en flyttad eller ommappad datasökväg. Kontrollera körtidsprocessens UID/GID, datakatalogens ägare, ledigt utrymme och om containerns montering är skrivbar innan du reparerar uppgiftsinställningar.

Jellyfins felsökningsdokumentation innehåller vägledning om databaslås vid misslyckade skanningar, medan containerdokumentationen visar att beständig lagring av konfiguration och cache beror på de monterade sökvägarna. Jellyfins beständiga containersökvägar

Om loggarna visar fel om databaslås ska du minska det specifika parallella arbetet eller följa den dokumenterade felsökningsvägen för databaslås i stället för att radera databasen. Om loggarna visar behörighetsfel eller skrivskyddade sökvägar ska du åtgärda den exakta datasökvägen och köra samma uppgift igen.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Bekräfta att medielagringen finns innan du kör biblioteksarbete

En skanning eller underhållsuppgift kan inte fungera normalt när en av mediesökvägarna saknas, inte är monterad eller är tillfälligt långsam. Kontrollera från både värden och Jellyfin-körtiden att samma bibliotekssökväg finns och är läsbar innan du kör jobbet manuellt igen.

Jellyfin varnar för att schemalagt underhåll kan ta bort objekt när medielagringen inte är tillgänglig. Varning om lagring vid schemalagt underhåll Därför är ”kör bara skanningen igen” ett dåligt första steg om en NAS eller extern disk inte har monterats korrekt.

Om uppgiften slutförs när monteringen återställs var workern inte grundorsaken. Åtgärda monteringsordningen eller lagringens tillförlitlighet och kontrollera igen efter en omstart av värden, så att sökvägen är tillgänglig innan Jellyfins normala underhållsfönster.

Isolera plugin- och uppgiftsspecifika beroenden

När endast ett pluginägt eller funktionsspecifikt jobb misslyckas ska du undersöka den komponenten i stället för att ändra globala Jellyfin-inställningar. Jämför om felet började efter en pluginuppdatering, serveruppgradering, sökvägsändring eller ändring av ett beroende.

Behåll huvudservern, databasen och orelaterade uppgifter intakta medan du endast inaktiverar eller återställer den misstänkta valfria komponenten. ZimaSpaces metod för återställning av en enskild tjänst följer samma princip: bevara fungerande beroenden medan en felande tjänst isoleras.

Om jobbet ingår i Jellyfins kärnfunktioner och loggarna pekar på en versionsspecifik regression ska du spara loggarna och den exakta serverversionen innan du eskalerar. Generalisera inte ett pluginfel till ett skäl att återskapa all beständig data.

Starta om endast som ett valideringssteg

Efter att du har korrigerat ett bekräftat beroende ska du starta den felande uppgiften manuellt och kontrollera att den når förväntad slutförandestatus. Starta sedan om Jellyfin en gång och kör uppgiften igen, eller vänta tills nästa schemalagda körning, för att bevisa att korrigeringen överlever normal tjänsteuppstart.

En omstart som tillfälligt tar bort symptomet utan att förklara det felande beroendet är ingen hållbar reparation. Om problemet återkommer ska du jämföra det nya första felet med det ursprungliga i stället för att samtidigt lägga till fler ändringar av behörigheter, databas och plugin.

Avsluta när måluppgiften slutförs efter omstart, det förväntade resultatet visas och annat schemalagt arbete fortfarande fungerar. Eskalera med uppgiftens namn, version, första fel, status för datasökvägen och stegen för att återskapa felet om samma kärnuppgift fortfarande misslyckas trots att lagring och behörigheter har bekräftats.