Jak sprawdzić, czy błąd Jellyfin pochodzi z klienta, czy z serwera

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.

How to Tell Whether a Jellyfin Error Comes From the Client or Server - Zima Store Online

Błąd Jellyfin zwykle podąża za klientem, gdy jedno urządzenie zawodzi, a klient kontrolny działa, oraz podąża za serwerem, gdy wiele klientów zawodzi przy tej samej ścieżce multimediów. Zanim zmienisz kodeki lub sprzęt, rozpocznij od lokalnego testu kontrolnego.

Porównując klienta, którego dotyczy problem, ze sprawdzonym klientem, zachowaj bez zmian serwer, konto, multimedia i jakość, a następnie porównaj bezpośrednie lokalne odtwarzanie ze ścieżką zdalną lub przekierowaną przez proxy. Wynik pokaże, czy należy zmienić możliwości klienta, ustawienia transkodowania Jellyfin lub routing sieciowy, a także kiedy przerwać diagnostykę z powodu niejednoznacznych danych.

Użyj klienta kontrolnego na tym samym serwerze

Jeden klient zgłasza błąd odtwarzania. Rozpocznij od najmniej inwazyjnego sprawdzenia: odtwórz ten sam element przy użyciu tego samego konta i tej samej jakości na kliencie kontrolnym. test kontrolny na tym samym serwerze

Istotna jest konkretna obserwacja: test kontrolny kończy się powodzeniem, oba testy kończą się niepowodzeniem albo klient kontrolny wybiera inny tryb odtwarzania. Zapisz wynik, zanim zmienisz kolejną zmienną.

Interpretuj poszczególne gałęzie zamiast zgadywać. Jeśli zawodzi tylko klient, którego dotyczy problem, bardziej prawdopodobna jest granica po stronie klienta; jeśli zawodzą oba, sprawdź serwer lub trasę; jeśli tryby się różnią, najpierw porównaj ścieżkę kodeka i napisów.

Sprawdź tryb odtwarzania i logi serwera

Klient kontrolny również zawodzi lub żąda tej samej ścieżki serwera. Rozpocznij od najmniej inwazyjnego sprawdzenia: porównaj tryb odtwarzania w panelu oraz odpowiadające mu wpisy w logach FFmpeg lub serwera dla sesji problematycznej i kontrolnej.

Istotna jest konkretna obserwacja: bezpośrednie odtwarzanie kończy się niepowodzeniem w obu przypadkach, transkodowanie kończy się w obu przypadkach albo tylko jeden klient transkoduje. Zapisz wynik, zanim zmienisz kolejną zmienną. dowody w logach FFmpeg

Interpretuj poszczególne gałęzie zamiast zgadywać. Jeśli obie sesje mają ten sam błąd serwera, bardziej prawdopodobna jest granica po stronie serwera; jeśli tylko jedna sesja transkoduje, wróć do możliwości klienta; jeśli logi są czyste, przetestuj trasę i stan przeglądarki.

Porównaj ścieżki bezpośrednią lokalną i zdalną

Przypisanie winy klientowi lub serwerowi nie jest rozstrzygające. Rozpocznij od najmniej inwazyjnego sprawdzenia: użyj tego samego klienta i tych samych multimediów za pośrednictwem lokalnego adresu LAN, a następnie zdalnego adresu lub adresu przekierowanego przez proxy.

Istotna jest konkretna obserwacja: lokalnie odtwarzanie działa, zdalnie zawodzi; oba połączenia zawodzą; zdalnie działa, a lokalnie zawodzi. Zapisz wynik, zanim zmienisz kolejną zmienną. ścieżka lokalna a zdalna

Interpretuj poszczególne gałęzie zamiast zgadywać. Jeśli zawodzi tylko połączenie zdalne, ogranicz zakres poszukiwań do proxy, DNS, routingu lub przepustowości; jeśli zawodzą oba połączenia, wróć do dowodów dotyczących serwera; jeśli zawodzi tylko połączenie lokalne, sprawdź powiązanie interfejsu lub lokalny DNS.

-15% OFF

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

Single board computer zimaboard2

Ponownie sprawdź pierwotny czynnik wywołujący problem i zakończ na właściwym właścicielu

Odpowiedzialność przypisuje się warunkowo. Rozpocznij od najmniej inwazyjnego sprawdzenia: zastosuj jedną ukierunkowaną zmianę, a następnie ponownie uruchom pierwotną sesję oraz jedną sesję kontrolną.

Istotna jest konkretna obserwacja: pierwotna sesja działa, a sesja kontrolna pozostaje stabilna; pierwotna sesja nadal zawodzi; oba połączenia ulegają zmianie. Zapisz wynik, zanim zmienisz kolejną zmienną.

Interpretuj poszczególne gałęzie zamiast zgadywać. Jeśli pierwotna sesja działa, a sesja kontrolna pozostaje stabilna, zakończ diagnostykę; jeśli nadal zawodzi, cofnij zmianę i przekaż problem dalej w ramach ustalonego właściciela; jeśli zmieniają się oba połączenia, wróć do najwcześniejszej niekontrolowanej zmiennej.