Dlaczego Jellyfin działa szybciej na niektórych klientach niż na innych

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.

Why Jellyfin Feels Faster on Some Clients Than Others - Zima Store Online

Jellyfin może działać znacznie szybciej na jednym kliencie niż na innym, ponieważ możliwości odtwarzania i działanie aplikacji zmieniają zakres pracy wykonywanej po obu stronach.

Natwna aplikacja na telewizor, przeglądarka, telefon i odtwarzacz na komputerze nie mają identycznej obsługi kodeków, strategii buforowania, sprzętowego dekodowania ani implementacji interfejsu. Jeden klient może korzystać z bezpośredniego odtwarzania, podczas gdy inny uruchamia konwersję, a jeszcze inny może wydajniej renderować ekrany biblioteki przy użyciu tego samego serwera. Porównuj klientów z tymi samymi multimediami, siecią i stanem serwera, aby ustalić, czy różnica wynika z możliwości klienta, czy z działania interfejsu.

Obsługa kodeków może zmienić obciążenie serwera

Najważniejsza jest kwestia tego, czy klient obsługuje źródłowy format wideo, dźwięku i kontenera, tryb HDR oraz napisy. Nieobsługiwany element może zmienić prosty odczyt pliku w pełne transkodowanie.

To samo źródło HEVC może korzystać z różnych ścieżek zgodności klienta na urządzeniach Android TV i klientach działających w stylu przeglądarki.

Odtwórz jeden znany plik na każdym kliencie i zanotuj, czy używane jest bezpośrednie odtwarzanie, remuksowanie czy transkodowanie. Jeśli wolniejszy klient tworzy większe obciążenie serwera, różnica wydajności nie wynika wyłącznie z opóźnienia interfejsu.

Sprzętowe dekodowanie wpływa na płynność po stronie klienta

Klient, który może korzystać z dekodera urządzenia, odtwarza materiały o wysokiej przepływności przy mniejszym obciążeniu lokalnego procesora niż klient polegający na słabszym dekodowaniu programowym. Może to wpływać na uruchamianie odtwarzania, przewijanie, liczbę pomijanych klatek i zużycie baterii.

To samo urządzenie Android TV może działać inaczej po zmianie ścieżki wyjścia audio; działanie przekazywania dźwięku E-AC3 zamroziło bezpośrednie odtwarzanie w przypadku, w którym lokalne dekodowanie PCM pozwoliło uniknąć błędu.

Zachowaj stałe ustawienia serwera i sieci, zmieniając wyłącznie klienta odtwarzania. Jeśli te same multimedia zaczynają działać płynnie bez zmian po stronie serwera, należy zwrócić uwagę na dekodowanie lub buforowanie po stronie klienta.

Responsywność interfejsu to inny pomiar

Płynne odtwarzanie nie gwarantuje szybkiego wyświetlania siatek plakatów ani wyszukiwania, ponieważ żądania interfejsu biblioteki zależą od dostępu do metadanych, zapytań do bazy danych, ładowania obrazów i renderowania po stronie klienta. Nawigację i odtwarzanie traktuj jako osobne testy wydajności.

Problemy z powolnym panelem wskazują na ścieżki ładowania metadanych i interfejsu jako odrębny problem wydajnościowy, niezwiązany bezpośrednio z dostarczaniem strumienia.

Mierz osobno czas otwarcia biblioteki, wyszukiwania i wyświetlenia pierwszej klatki. Procedurę diagnozowania buforowania odtwarzania stosuj wyłącznie na etapie strumienia, który rzeczywiście działa wolno.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Użyj sprawdzonego klienta jako punktu odniesienia

Bez punktu odniesienia zmiana na serwerze może sprawiać wrażenie, że naprawiła jeden z klientów, podczas gdy w rzeczywistości zmieniła tylko sposób podejmowania przez niego decyzji dotyczącej odtwarzania. Stabilny punkt końcowy ułatwia klasyfikowanie regresji między klientami.

Metoda USE pomaga potwierdzić, czy profil wykorzystania zasobów serwera rzeczywiście zmienia się podczas korzystania z wolniejszego klienta.

Po aktualizacji aplikacji lub serwera zachowaj jednego klienta, jeden plik multimedialny i jedno ustawienie jakości jako powtarzalny punkt odniesienia. Zbadaj pierwszą rozbieżną metrykę, zamiast jednocześnie dostrajać każdą warstwę.