Dlaczego Plex sporadycznie przestaje działać, gdy wiele urządzeń jednocześnie odtwarza treści?

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.

Okresowe problemy z Plexem przy korzystaniu z wielu klientów zwykle można zdiagnozować, obserwując, który strumień jako pierwszy zmienia charakter: transkodowanie, przepustowość, operacje wejścia/wyjścia pamięci masowej czy ścieżka związana z konkretnym klientem.

Serwer, który działa stabilnie z jednym telewizorem, może nadal przestać działać, gdy telefon, zdalna przeglądarka i telewizor Smart TV rozpoczną odtwarzanie różnych plików w tym samym czasie. Klienci mogą generować różne obciążenia: jeden może korzystać z funkcji Direct Play, podczas gdy inny wymusza transkodowanie wideo, wypalanie napisów lub połączenie przez WAN. Odtwórz problem, dodając klientów pojedynczo, i użyj panelu Plex Dashboard, aby przed zmianą limitów lub sprzętu zarejestrować, co faktycznie robi każda sesja.

Ustal bazę dla jednego strumienia przed testowaniem współbieżności

Rozpocznij od kombinacji klienta i pliku, która najczęściej powoduje problem, ale uruchom tylko ten jeden strumień. Zapisz, czy Plex zgłasza Direct Play, Direct Stream czy Transcode, i zwróć uwagę na zachowanie procesora, układu GPU, sieci oraz dysku. Jeśli strumień zawiedzie samodzielnie, współbieżność nie jest główną przyczyną i należy przerwać dalszy test.

Plex wyjaśnia, że wydajność strumieniowania serwera jest ograniczana głównie przez moc obliczeniową i przepustowość sieci, gdy używane jest transkodowanie lub odtwarzanie zdalne. To rozróżnienie ma znaczenie, ponieważ serwer może obsłużyć wiele sesji Direct Play, ale szybko osiągnąć limit, gdy kilku klientów zażąda konwersji.

Jeśli test bazowy przebiegł prawidłowo, dodaj drugiego klienta bez zmieniania pierwszego. Następnie dodawaj klientów pojedynczo, aż pojawi się pierwsza możliwa do zaobserwowania awaria. Strumień dodany w momencie wystąpienia problemu jest bardziej miarodajny niż przypadkowy komunikat o błędzie, ponieważ wskazuje, które nowe obciążenie zmieniło stan serwera.

Użyj panelu Dashboard, aby odróżnić obciążenie transkodowaniem od obciążenia sieci

Gdy pojawi się problem, sprawdź każdą aktywną sesję w panelu Dashboard. Jeśli awaria zbiega się z rozpoczęciem nowego transkodowania sprzętowego lub programowego, przetestuj tego samego klienta z plikiem zgodnym z Direct Play albo ze ścieżką napisów o mniejszej złożoności. Jeśli błąd zniknie, głównym podejrzanym jest potok transkodowania.

Przewodnik ZimaSpace po akceleracji sprzętowej pomaga zrozumieć, dlaczego wiele strumieni może przenosić obciążenie z procesora na dostępny akcelerator oraz dlaczego serwer nadal potrzebuje zapasu mocy na pozostałe zadania NAS. Akceleracja sprzętowa nie oznacza nieograniczonej współbieżności — to tylko jedna ze ścieżek zasobów, którą należy zweryfikować.

Jeśli zawodzą tylko strumienie zdalne, a sesje lokalne działają prawidłowo, zmierz rzeczywistą przepustowość wysyłania z serwera w tym samym przedziale czasu i porównaj ją z łącznym zapotrzebowaniem strumieni. Jeśli jednocześnie zawodzą klienci lokalni i zdalni, skieruj diagnostykę w stronę mocy obliczeniowej lub pamięci masowej, zamiast uznawać łącze internetowe za wspólną przyczynę.

Sprawdź, czy kontener lub host osiąga limit w momencie awarii

Obserwuj kontener Plex i hosta podczas dodawania kolejnych strumieni. Ograniczenie procesora, nasycenie silnika wideo GPU, presja na pamięć lub wysokie oczekiwanie na operacje wejścia/wyjścia, które pojawiają się przy tej samej liczbie klientów, są bardziej konkretną wskazówką niż średnie wykorzystanie zasobów zmierzone po awarii. Ustal, który zasób jako pierwszy osiąga swój limit.

Polecenie container stats w Dockerze może podczas testu pokazywać wykorzystanie procesora i pamięci przez kontener, a także ruch sieciowy oraz operacje blokowego wejścia/wyjścia. Połącz te dane z widokiem sesji w Plex, aby ustalić, czy skok wykorzystania zasobów pochodzi z Plexa i jakie działanie klienta go wywołało.

Jeśli wykorzystanie zasobów pozostaje umiarkowane, ale jeden klient zawodzi, wymień tylko tego klienta lub plik multimedialny. Awaria, która podąża za konkretnym urządzeniem, kodekiem, formatem napisów lub ścieżką sieciową, należy do węższej gałęzi problemów ze zgodnością klienta. Nie zmniejszaj limitów obowiązujących cały serwer, aby rozwiązać problem odtwarzalny tylko na jednym urządzeniu.

-15% OFF

Zastosuj najmniejszą dopasowaną poprawkę i ponownie przetestuj tę samą kombinację klientów

W przypadku potwierdzonego limitu transkodowania ogranicz niepotrzebne transkodowanie, zweryfikuj działanie akceleracji sprzętowej albo ustaw świadomy limit jednoczesnych transkodowań, pozostawiając NAS-owi zapas zasobów. W przypadku potwierdzonego wąskiego gardła wysyłania dostosuj jakość zdalnych strumieni lub zwiększ dostępną przepustowość wysyłania. W przypadku operacji wejścia/wyjścia pamięci masowej przetestuj osobno ścieżki plików multimedialnych i tymczasowych plików transkodowania, zanim cokolwiek przeniesiesz.

Powtórz dokładną sekwencję klientów, która pierwotnie powodowała awarię, i utrzymuj ją wystarczająco długo, aby przekroczyć dawny punkt graniczny. Skuteczna poprawka oznacza, że ta sama liczba i kombinacja klientów pozostaje stabilna przy tych samych formatach multimediów oraz w tych samych warunkach zdalnego i lokalnego odtwarzania — nie tylko że pojedynczy film testowy zaczyna się odtwarzać.

Jeśli awaria nadal występuje nieregularnie i nie koreluje z żadnym zasobem, zbierz dzienniki serwera Plex z sygnaturami czasu rozpoczęcia i awarii każdej sesji klienta. Zgłoszenie powinno zawierać modele klientów, wersje aplikacji Plex, wersję serwera, szczegóły plików multimedialnych oraz pierwszy krok współbieżności, przy którym wystąpiła awaria, aby dalsza diagnostyka mogła rozpocząć się od powtarzalnych danych.

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.