Ostrzeżenie Jellyfin można bezpiecznie monitorować tylko wtedy, gdy znany jest jego zakres, przyczyna nie narasta, a odtwarzanie, operacje zapisu i odzyskiwanie nadal przebiegają pomyślnie.
Czy ostrzeżenie pojawia się raz podczas skanowania, czy powtarza się wraz z błędami bazy danych, brakującymi plikami, zabiciem procesu przez OOM lub nieudanymi restartami? Przed podjęciem decyzji zapisz dokładny komunikat, znacznik czasu, wersję, ścieżkę, której dotyczy problem, oraz aktywne obciążenie. Nie ignoruj ostrzeżenia tylko dlatego, że panel pozostaje dostępny.
Klasyfikuj ostrzeżenie według operacji, której może zaszkodzić
Ostrzeżenia dotyczące pojedynczego niedostępnego elementu grafiki lub przejściowej ponownej próby klienta można zwykle monitorować, jeśli kolejne skanowanie i odtwarzanie przebiegną pomyślnie. Ostrzeżenia dotyczące małej ilości wolnego miejsca, zapisu do bazy danych, utraty montowania, uprawnień lub powtarzającego się kończenia procesu mają większy zakres potencjalnej awarii. W rzeczywistych incydentach Jellyfin pełny wolumen danych wiązano z błędami SQLite i znikającymi rekordami użytkowników (dowody awarii przy pełnym dysku).
Sprawdź, czy ostrzeżenie ogranicza się do logów, czy ta sama operacja zmienia stan systemu. Jeśli skanowanie usuwa lub ponownie zapisuje dane biblioteki, gdy montowanie jest niedostępne, zatrzymaj zadanie i przywróć ścieżkę przed kontynuowaniem.
Po pierwszym uruchomieniu porównaj ten sam komunikat z kolejnym zaplanowanym zadaniem. Ostrzeżenie, które znika bez zmiany obciążenia, wiąże się z mniejszym ryzykiem niż ostrzeżenie powracające przy tej samej operacji.
Stosuj decyzję o monitorowaniu opartą na dwóch testach
Powtórz pierwotny wyzwalacz raz w kontrolowanych warunkach i sprawdź dotknięty podsystem: wolne bajty i i-węzły w przypadku pamięci masowej, memory.events w przypadku OOM, logi ffmpeg w przypadku odtwarzania oraz właściciela plików w przypadku błędów zapisu. Ostrzeżenie, które znika bez zmiany obciążenia, wiąże się z mniejszym ryzykiem niż ostrzeżenie powracające na tym samym etapie.
Monitoruj, gdy drugi przebieg zakończy się pomyślnie, zakres ostrzeżenia nie rozszerzy się i istnieje aktualna kopia zapasowa. Zatrzymaj działanie, gdy ostrzeżenie powtarza się wraz z utratą danych, błędami bazy danych, nieudanymi zapisami lub pętlą restartów. Ścieżka diagnostyki odtwarzania pomaga odróżnić ostrzeżenie od rzeczywistej awarii streamingu.
Zapisz dokładny wynik: liczbę wolnych bajtów i i-węzłów, stan zapisu do bazy danych, kod zakończenia procesu lub tryb odtwarzania. Ten wynik określa, czy następnym krokiem będzie obserwacja, naprawa czy wycofanie zmian.
Zatrzymaj działanie, zachowaj dane i bezpiecznie eskaluj problem
Zatrzymaj aktywne skanowanie lub import, zachowaj logi i unikaj destrukcyjnego czyszczenia, gdy problem może dotyczyć bazy danych lub ścieżki pamięci masowej. Przywróć wolne miejsce albo brakujące montowanie, a następnie wykonaj jeden restart jako punkt kontrolny weryfikacji — nie jako rozwiązanie problemu. Powtórz pierwotne obciążenie i potwierdź, że ostrzeżenie nie wpływa już na tę samą operację.
Eskaluj problem, gdy ostrzeżenie utrzymuje się po odwracalnych testach, nie można otworzyć bazy danych albo bazowy dysk, system plików lub środowisko uruchomieniowe kontenera zgłasza błędy. Zachowaj ostatnią poprawną kopię zapasową oraz ścieżkę stanu.
Jeśli naprawa zakończy się pomyślnie, powtórz pierwotny wyzwalacz po pełnym restarcie i potwierdź, że ostrzeżenie nie wraca. Sam fakt, że panel się otwiera, nie wystarcza, jeśli to samo skanowanie lub zapis nadal kończy się niepowodzeniem.
Potwierdź granicę po poprawnym restarcie
Po odwracalnym teście zrestartuj Jellyfin raz, a następnie powtórz to samo skanowanie, import lub odtwarzanie, które wywołało ostrzeżenie. Nie zmieniaj obciążenia ani ścieżki pamięci masowej, aby porównanie było miarodajne.
Monitoruj, gdy operacja zakończy się pomyślnie, zakres ostrzeżenia się nie rozszerzy, a kolejna kopia zapasowa pozostanie możliwa do odczytu. Zatrzymaj działanie, gdy ostrzeżenie powróci wraz z błędami bazy danych, pamięci masowej, uprawnień lub powtarzającymi się błędami procesu.
Eskaluj problem, przekazując zachowane logi i ostatni poprawny stan, gdy ten sam wyzwalacz zawiedzie po restarcie, nie można otworzyć bazy danych albo bazowy system plików zgłasza błędy.
Wsparcie i wskazówki
Więcej do przeczytania

Jak zoptymalizować połączenia z bazą danych Jellyfin dla kontenerów działających równocześnie
Zacznij od jednego właściciela bazy danych i zmierz zachowanie blokad SQLite; dodaj inny backend dopiero wtedy, gdy współbieżność i odzyskiwanie danych uzasadnią tę złożoność.

Jak zapobiegać duplikowaniu zadań lub importów w Jellyfin
Duplikowanie pracy zwykle wynika z nakładających się harmonogramów lub więcej niż jednego procesu zapisującego; wyznacz jednego właściciela, jedną ścieżkę i jeden sposób sprawdzania ukończenia.

Jak naprawić Jellyfin po zapełnieniu woluminu bazy danych
Wstrzymaj zapisy, zachowaj bazę danych i pliki WAL, zwolnij miejsce bez bezmyślnego usuwania stanu, a następnie zweryfikuj integralność i pierwotne działanie.

