Jellyfin uruchamia się, ale jego procesy działające w tle pozostają offline

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

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

Jellyfin nie udostępnia jednej uniwersalnej usługi procesów roboczych działającej osobno od serwera WWW. Jeśli interfejs się ładuje, ale „procesy robocze” są wyświetlane jako offline, przełóż ten objaw na konkretną operację w tle, która utknęła: skanowanie biblioteki, odświeżanie metadanych, zadanie generowania obrazów rozdziałów, zadanie wtyczki lub inne zaplanowane zadanie.

To rozróżnienie ma znaczenie, ponieważ sprawny punkt końcowy HTTP potwierdza jedynie uruchomienie głównego procesu serwera. Następnie wskaż jedno zadanie, które powinno się wykonać, sprawdź wynik ostatniego uruchomienia i odpowiadające mu wpisy w dzienniku, a potem prześledź pierwszą niesprawną zależność — bazę danych, zapisywalne dane aplikacji, magazyn multimediów, wtyczkę lub zasób właściwy dla danego zadania — zamiast przebudowywać serwer, który już udostępnia interfejs.

Zidentyfikuj dokładne zadanie w tle, które nie postępuje

Otwórz panel i wybierz jedno zaplanowane zadanie, którego działanie możesz obserwować. Zapisz czas ostatniego uruchomienia, czas następnego uruchomienia, bieżący stan oraz to, czy ręczne uruchomienie cokolwiek zmienia. Nie traktuj wszystkich bezczynnych zaplanowanych zadań jako jednego objawu „wyłączonych procesów roboczych”.

Drzewo źródeł Jellyfin dokumentuje dedykowaną implementację ScheduledTasks na serwerze, potwierdzając, że konserwacja w tle jest obsługiwana jako osobne zaplanowane operacje, a nie przez drugi, ogólny demon. Implementacja ScheduledTasks w Jellyfin

Jeśli jedno zadanie kończy się błędem, a pozostałe są wykonywane, prowadź analizę tylko dla tego zadania. Jeśli każde zadanie odmawia uruchomienia, poszukaj wspólnej zależności, takiej jak stan bazy danych, uprawnienia do katalogu danych lub migracja podczas uruchamiania, zanim zmienisz ustawienia poszczególnych bibliotek.

Odczytaj pierwszy istotny błąd, a nie ostatnią kaskadę błędów

Przejrzyj dzienniki Jellyfin z czasu uruchomienia zadania. Wyszukaj nazwę zadania, a następnie cofnij się do pierwszego ostrzeżenia lub błędu wyjaśniającego, dlaczego zadanie nie mogło uzyskać blokady bazy danych, otworzyć ścieżki, zapisać danych aplikacji, uruchomić FFmpeg lub załadować zależności wtyczki.

Dokumentacja rozwiązywania problemów Jellyfin zaleca korzystanie z dzienników jako pierwszego miejsca diagnozowania problemów z serwerem i odtwarzaniem oraz informuje, że rejestrowanie debugowania może generować bardzo dużą ilość danych. Wskazówki Jellyfin dotyczące rejestrowania zdarzeń

Włącz rejestrowanie debugowania tylko wtedy, gdy zwykłe dzienniki nie pokazują odpowiedniej ścieżki, odtwórz jedną próbę wykonania zadania, a następnie przywróć normalny poziom rejestrowania. Kontrolowane odtworzenie problemu jest bardziej użyteczne niż pozostawienie włączonych dzienników debugowania, gdy kilka niezwiązanych zaplanowanych zadań generuje szum.

Sprawdź, czy można zapisywać w katalogu danych i czy baza danych może kontynuować pracę

Interfejs WWW może się wyświetlać nawet wtedy, gdy późniejsza operacja w tle nie może zapisać danych w przeniesionej lub ponownie mapowanej ścieżce danych. Przed naprawą ustawień zadania sprawdź identyfikator UID/GID procesu, właściciela katalogu danych, wolne miejsce oraz to, czy podłączenie kontenera jest zapisywalne.

Dokumentacja rozwiązywania problemów Jellyfin zawiera wskazówki dotyczące blokad bazy danych przy nieudanych skanach, a dokumentacja kontenerów pokazuje, że trwałość konfiguracji i pamięci podręcznej zależy od zamontowanych ścieżek. Trwałe ścieżki kontenera Jellyfin

Jeśli dzienniki pokazują błędy blokady bazy danych, ogranicz konkretną równoległą pracę lub postępuj zgodnie z udokumentowaną procedurą rozwiązywania problemów z blokadą bazy danych, zamiast usuwać bazę. Jeśli dzienniki pokazują błędy uprawnień lub tylko do odczytu, napraw dokładnie tę ścieżkę danych i ponownie uruchom to samo zadanie.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Potwierdź dostępność magazynu multimediów przed uruchomieniem prac biblioteki

Skanowanie lub zadanie konserwacyjne nie będzie działać prawidłowo, gdy jedna ze ścieżek multimediów jest niedostępna, niezamontowana lub działa niestabilnie. Na hoście i w środowisku uruchomieniowym Jellyfin sprawdź, czy ta sama ścieżka biblioteki istnieje i jest odczytywalna, zanim ręcznie ponownie uruchomisz zadanie.

Jellyfin ostrzega, że zaplanowana konserwacja może usuwać elementy, gdy magazyn multimediów jest niedostępny. Ostrzeżenie dotyczące magazynu przy zaplanowanej konserwacji Dlatego „po prostu ponownie uruchom skanowanie” jest złym pierwszym krokiem, jeśli serwer NAS lub dysk zewnętrzny nie został prawidłowo zamontowany.

Jeśli przywrócenie montowania pozwoli na ukończenie zadania, proces roboczy nie był przyczyną źródłową. Napraw kolejność montowania lub niezawodność magazynu i sprawdź ponownie po ponownym uruchomieniu hosta, aby ścieżka była dostępna przed standardowym oknem konserwacji Jellyfin.

Odizoluj zależności wtyczek i zależności właściwe dla zadania

Gdy nie działa tylko jedno zadanie należące do wtyczki lub konkretnej funkcji, sprawdź ten komponent zamiast zmieniać globalne ustawienia Jellyfin. Porównaj, czy problem zaczął się po aktualizacji wtyczki, aktualizacji serwera, zmianie ścieżki lub zmianie zależności.

Pozostaw główny serwer, bazę danych i niezwiązane zadania bez zmian, wyłączając lub wycofując tylko podejrzany opcjonalny komponent. Podejście ZimaSpace do odzyskiwania pojedynczej usługi opiera się na tej samej zasadzie: zachowaniu sprawnych zależności i odizolowaniu jednej niesprawnej usługi.

Jeśli zadanie jest częścią podstawowego Jellyfin, a dzienniki wskazują na regresję zależną od wersji, zachowaj dzienniki i dokładną wersję serwera przed zgłoszeniem problemu. Nie traktuj awarii wtyczki jako powodu do odtwarzania wszystkich danych trwałych.

Uruchamiaj ponownie tylko jako etap weryfikacji

Po naprawieniu jednej potwierdzonej zależności ręcznie uruchom nieudane zadanie i sprawdź, czy osiągnie oczekiwany stan ukończenia. Następnie raz uruchom ponownie Jellyfin i ponownie wykonaj zadanie lub zaczekaj na jego następne zaplanowane uruchomienie, aby potwierdzić, że poprawka działa po standardowym uruchomieniu usługi.

Ponowne uruchomienie, które tymczasowo usuwa objaw bez wyjaśnienia niesprawnej zależności, nie jest trwałą naprawą. Jeśli problem powróci, porównaj nowy pierwszy błąd z pierwotnym zamiast jednocześnie dodawać kolejne zmiany uprawnień, bazy danych i wtyczek.

Zakończ działania, gdy docelowe zadanie zakończy się po ponownym uruchomieniu, pojawi się oczekiwany wynik, a pozostałe zaplanowane zadania nadal będą działać prawidłowo. Jeśli to samo podstawowe zadanie nadal kończy się błędem mimo potwierdzonego dostępu do magazynu i prawidłowych uprawnień, zgłoś problem, podając nazwę zadania, wersję, pierwszy błąd, stan ścieżki danych oraz kroki odtworzenia.