Czy Jellyfin może działać podczas tymczasowej awarii Internetu?

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.

Can Jellyfin Keep Working During a Temporary Internet Outage?

Tak. Jellyfin może nadal udostępniać lokalne multimedia podczas tymczasowej awarii internetu, jeśli serwer, magazyn multimediów, sieć LAN i klient mogą nadal komunikować się ze sobą lokalnie.

Ważne zastrzeżenie jest takie, że określenie „Jellyfin jest hostowany samodzielnie” nie oznacza, że każda powiązana zależność jest odporna na brak internetu. Publiczny DNS, tunel w chmurze, zdalny dostawca metadanych, zewnętrznie hostowany niestandardowy CSS, a nawet własny ekran startowy urządzenia do strumieniowania mogą przestać działać, podczas gdy sam serwer Jellyfin pozostaje sprawny. Przed poleganiem na nim podczas awarii przetestuj całą lokalną ścieżkę odtwarzania.

Oddziel utratę internetu od utraty sieci lokalnej

Awaria sieci WAN oznacza, że router nie może już połączyć się z internetem; nie musi to oznaczać, że przełącznik Ethernet, punkt dostępu Wi-Fi, DHCP i routing lokalny przestają działać. Umieść serwer i klienta w tej samej działającej sieci LAN oraz przetestuj serwer Jellyfin za pomocą lokalnego adresu lub lokalnej nazwy DNS.

Testy awarii przeprowadzane przez społeczność regularnie potwierdzają, że lokalne odtwarzanie może być kontynuowane, gdy dostęp WAN jest niedostępny, jednocześnie wskazując, że niektóre urządzenia klienckie mogą mieć własne zależności internetowe. Ta różnica jest powodem, dla którego serwer i klienta trzeba testować oddzielnie.

Jeśli sam router uruchamia się ponownie w trybie wyłączającym Wi-Fi lub lokalny DNS w przypadku braku sieci WAN, najpierw napraw działanie tej sieci. Jellyfin nie może obsłużyć klienta, który nie ma już trasy do hosta, mimo że aplikacja nie wymaga uwierzytelniania w chmurze.

Zapewnij klientom lokalnym trasę niezależną od publicznego DNS-u i tunelu w chmurze

Jeśli każdy telewizor uzyskuje dostęp do Jellyfin wyłącznie przez publiczną nazwę hosta, której DNS, odwrotne proxy lub tunel zależy od internetu, lokalna usługa może wyglądać na niedostępną podczas awarii WAN. Zapisz lokalny adres IP lub lokalną nazwę DNS jako udokumentowaną opcję awaryjną albo skonfiguruj dzielony DNS, aby zwykła nazwa używana w domu rozwiązywała się lokalnie, gdy klienci znajdują się w sieci domowej.

Lokalna trasa powinna kończyć się wewnątrz sieci LAN i prowadzić do tej samej docelowej instancji Jellyfin bez przekierowywania przez VPS lub usługę w chmurze. Przetestuj działanie certyfikatu i nazwy hosta wymagane przez używane urządzenia; niektóre aplikacje akceptują bezpośredni lokalny adres HTTP jako opcję awaryjną, podczas gdy inne są skonfigurowane wokół jednego zapisanego adresu HTTPS.

Wyjaśnienie ZimaSpace dotyczące lokalnego i zdalnego dostępu jako oddzielnych ścieżek stanowi właściwy model myślowy: awaria ścieżki WAN nie musi powodować awarii ścieżki LAN.

Przygotuj się na pogorszenie działania metadanych i integracji zależnych od internetu

Już zapisane multimedia, stan bazy danych, grafiki i metadane mogą pozostać dostępne lokalnie. Nowe wyszukiwania metadanych, aktualizacje wtyczek, pobieranie napisów, zdalne zasoby graficzne i inne połączenia z zewnętrznymi dostawcami mogą kończyć się niepowodzeniem lub oczekiwać na przekroczenie limitu czasu do chwili przywrócenia internetu.

Test społeczności dotyczący Jellyfin z lokalnymi multimediami bez dostępu do internetu wskazuje, że istniejące lokalne metadane pozostają użyteczne, podczas gdy nowe skanowanie jest niedostępne. Projektuj działanie podczas awarii z myślą o lokalnie buforowanych zasobach, zamiast zakładać, że każda funkcja wzbogacania treści należy do podstawowej ścieżki odtwarzania.

Jeśli niestandardowy motyw pobiera czcionki lub CSS z publicznego adresu URL, hostuj te zasoby lokalnie, jeśli są ważne dla interfejsu działającego offline. Podobnie unikaj uzależniania lokalnych użytkowników domowych od zdalnej bramy tożsamości, chyba że świadomie akceptujesz tę zależność podczas awarii.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Testuj urządzenie klienckie, a nie tylko stronę Jellyfin w przeglądarce

Niektóre platformy telewizorów smart i przystawki do strumieniowania wymagają dostępu do internetu na ekranie głównym, podczas uruchamiania aplikacji, weryfikacji konta lub na potrzeby usług platformy, nawet jeśli klient Jellyfin może komunikować się lokalnie po uruchomieniu. To, że przeglądarka na laptopie działa podczas awarii, nie dowodzi, że urządzenie w salonie również zadziała.

Relacje użytkowników opisują zachowanie zależne od klienta w sieci LAN bez internetu, dlatego platforma urządzenia jest częścią projektu dostępności. Przetestuj każdą klasę klientów, z której rodzina będzie oczekiwać korzystać.

Zachowaj co najmniej jednego klienta awaryjnego, który może otworzyć lokalny adres URL bez uruchamiania usług w chmurze. Może to być laptop, tablet, HTPC lub inne urządzenie, które zostało faktycznie przetestowane. Celem nie jest przewidzenie zachowania każdego producenta, lecz sprawdzenie jednej użytecznej domowej ścieżki przed kolejną awarią.

Przeprowadź kontrolowany test odłączenia sieci WAN

Nie testuj tego przez wyłączanie routera lub Wi-Fi. Odłącz albo zablokuj wyłącznie łącze WAN, pozostawiając sieć lokalną bez zmian. Następnie otwórz Jellyfin po całkowitym ponownym uruchomieniu klienta, zaloguj się w razie potrzeby, przeglądaj istniejące metadane, uruchom plik w trybie Direct Play, uruchom transkodowanie, jeśli domownicy z niego korzystają, przewijaj, wznów odtwarzanie i przełączaj użytkowników.

Podczas testu zanotuj, które działania pozostają lokalne, a które kończą się przekroczeniem czasu oczekiwania na zewnętrznych usługach. Po ponownym połączeniu WAN sprawdź, czy nieudane zadania dotyczące metadanych lub aktualizacji zostają wznowione bez uszkodzenia stanu biblioteki. Jeśli interfejs zawiesza się, ponieważ zewnętrzne wywołania blokują lokalne działania, zapisz tę konkretną funkcję jako zależność podczas awarii.

Projekt można uznać za sprawdzony, gdy zwykły klient domowy może znaleźć serwer, uwierzytelnić się lokalnie, przeglądać zapisane treści i odtwarzać reprezentatywne multimedia podczas braku sieci WAN. Każdy element, który zawodzi, należy oznaczyć jako zależność od sieci lokalnej, platformy klienta, trasy publicznej lub zewnętrznej integracji, zamiast sprowadzać wszystko do stwierdzenia „Jellyfin potrzebuje internetu”.

FAQ

Czy istniejące plakaty i metadane Jellyfin znikną po awarii internetu?

Zwykle nie. Metadane i grafiki zapisane wcześniej przez serwer pozostają lokalne. Przestaje działać pobieranie nowych informacji od dostawców zależnych od internetu, dlatego nowo dodane multimedia lub wzbogacanie na żądanie mogą być niekompletne do czasu przywrócenia połączenia.

Dlaczego telefon może połączyć się z Jellyfin offline, a telewizor nie?

Serwer Jellyfin może działać prawidłowo, podczas gdy platforma telewizora ma własną zależność internetową dotyczącą ekranu startowego, uruchamiania aplikacji, DNS-u lub weryfikacji sieci. Przetestuj konkretny telewizor lub przystawkę podczas odłączenia wyłącznie sieci WAN i zachowaj lokalnego klienta awaryjnego, jeśli oglądanie podczas awarii jest ważne.