Jak sprawdzić, czy Jellyfin korzysta z oczekiwanego pliku konfiguracyjnego

Tak, możesz sprawdzić, czy Jellyfin korzysta z oczekiwanego katalogu konfiguracji, bez zgadywania na podstawie tego, gdzie przypadkiem znajduje się plik na hoście. Niezawodny test polega na ustaleniu kolejności rozstrzygania ścieżek Jellyfin, sprawdzeniu uruchomionego procesu lub ustawień kontenera, a następnie potwierdzeniu aktywnej ścieżki w dziennikach uruchamiania przed zmianą dowolnego pliku konfiguracyjnego.

Ma to znaczenie po przejściu z instalacji pakietowej na Dockera, sklonowaniu pliku Compose lub przywróceniu starszego serwera, ponieważ może istnieć kilka kopii plików network.xml, system.xml lub logging.json, podczas gdy aktywny jest tylko jeden katalog. Nie edytuj każdej kopii, dopóki objaw nie zniknie. Najpierw zidentyfikuj aktywny katalog konfiguracji, wprowadź jedną odwracalną zmianę i sprawdź, czy po ponownym uruchomieniu Jellyfin zgłasza tę samą ścieżkę.

Najpierw ustal kolejność rozstrzygania ścieżki konfiguracji

Zacznij od sprawdzenia, jak uruchomiono Jellyfin. Parametr wiersza poleceń --configdir ma pierwszeństwo przed zmienną środowiskową JELLYFIN_CONFIG_DIR, natomiast domyślne ścieżki platformy są używane tylko wtedy, gdy nie ustawiono parametrów o wyższym priorytecie.

Oficjalna dokumentacja kolejności rozstrzygania ścieżek konfiguracji opisuje priorytety ścieżek danych, konfiguracji, pamięci podręcznej i katalogu internetowego. Porównaj tę kolejność z jednostką usługi, środowiskiem kontenera lub poleceniem uruchamiającym, zanim uznasz, że aktywny jest znany katalog na hoście.

Jeśli ustawienie o wyższym priorytecie wskazuje nieoczekiwane miejsce, zatrzymaj się: znaleziona na dysku konkurencyjna kopia pliku nie jest dowodem, że Jellyfin ją odczytuje. Popraw konfigurację uruchamiania albo celowo pozostaw aktywną ścieżkę i ją udokumentuj.

Sprawdź uruchomiony kontener lub definicję usługi

W przypadku Dockera sprawdź działający kontener, a nie tylko przechowywany na dysku plik Compose. Uruchomiony obiekt pokaże, które zmienne środowiskowe i punkty montowania zostały faktycznie zastosowane podczas tworzenia kontenera.

Polecenie docker inspect zwraca szczegółowe informacje o działającym kontenerze, co ułatwia porównanie wartości środowiska i miejsc docelowych montowania z oczekiwanymi ścieżkami Jellyfin. Plik Compose zmieniony po utworzeniu kontenera może nie odpowiadać bieżącemu środowisku uruchomieniowemu.

W przypadku usługi natywnej sprawdź jednostkę systemd oraz każdy ładowany przez nią plik środowiskowy. Jeśli definicja środowiska uruchomieniowego nie zgadza się z Twoimi notatkami, zaufaj środowisku uruchomieniowemu, a następnie zdecyduj, czy odtworzyć usługę z zamierzoną ścieżką.

Potwierdź ścieżkę w informacjach z uruchamiania Jellyfin

Po zapisaniu oczekiwanej ścieżki uruchom usługę ponownie, a następnie odczytaj najwcześniejsze wpisy z uruchamiania Jellyfin. Poszukaj skonfigurowanych ścieżek danych, pamięci podręcznej lub przechowywania i porównaj je z definicją procesu lub kontenera, którą właśnie sprawdziłeś.

Nie traktuj pomyślnego logowania przez przeglądarkę jako dowodu, że aktywny jest właściwy katalog konfiguracji. Jellyfin może uruchomić się normalnie z nową lub starszą ścieżką konfiguracji i nadal wyświetlać prawidłowy interfejs, podczas gdy ustawienia użytkowników, sieć, wtyczki lub zadania zaplanowane będą pochodzić z niewłaściwego stanu.

Przy przenoszeniu serwera multimediów między metodami wdrażania ta sama dyscyplina dotycząca ścieżek odnosi się do całego stosu. Dobrym punktem wyjścia jest domowa konfiguracja centrum multimedialnego Jellyfin, w której ścieżka aplikacji, ścieżka multimediów i ścieżka dostępu są traktowane jako oddzielne elementy konfiguracji.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Użyj jednej nieszkodliwej zmiany konfiguracji jako testu rozstrzygającego

Jeśli dwa potencjalne katalogi nadal wydają się prawdopodobne, zatrzymaj Jellyfin przed edycją serwerowego pliku konfiguracyjnego XML. Wybierz jedno odwracalne ustawienie o wyraźnym działaniu i zmień je wyłącznie w podejrzanym aktywnym katalogu. Nie modyfikuj danych użytkowników, ścieżek bibliotek ani niczego, co mogłoby wywołać duże ponowne skanowanie tylko po to, aby potwierdzić wybór pliku.

Uruchom Jellyfin i sprawdź, czy wybrane ustawienie jest widoczne. Jeśli tak, ponownie zatrzymaj usługę, cofnij zmianę i uruchom ją jeszcze raz, aby potwierdzić jej trwałość. Jeśli nie, plik nie jest aktywny albo ustawienie o wyższym priorytecie je nadpisuje.

Ten kontrolowany test A/B wykonywany poza działającą usługą jest bardziej miarodajny niż porównywanie znaczników czasu, ponieważ narzędzia do tworzenia kopii zapasowych, aktualizacje pakietów i edytory mogą modyfikować nieaktywne pliki. Jellyfin opisuje te opcje konfiguracji jako zasadniczo statyczne i przeznaczone do ustawienia przed uruchomieniem serwera, dlatego unikaj edycji na żywo, chyba że konkretne ustawienie wyraźnie opisuje inne zachowanie.

Zakończ sprawdzanie, gdy aktywna ścieżka przetrwa ponowne uruchomienie

Wynik jest potwierdzony, gdy definicja środowiska uruchomieniowego, informacje z uruchamiania oraz jedna odwracalna zmiana konfiguracji wskazują ten sam katalog także po ponownym uruchomieniu. Zapisz tę ścieżkę w dokumentacji wdrożenia i zakresie kopii zapasowych.

Jeśli aktywna ścieżka zmieni się po ponownym utworzeniu kontenera, sprawdź, jak generowane są wolumin i zmienne środowiskowe, zamiast wielokrotnie edytować pliki Jellyfin. Problem leży wtedy w stanie wdrożenia, a nie w analizatorze konfiguracji Jellyfin.

Eskaluje sprawę tylko wtedy, gdy ścieżka środowiska uruchomieniowego jest jednoznaczna, ale Jellyfin konsekwentnie ignoruje prawidłowe ustawienie w aktywnym pliku. Zachowaj dziennik uruchamiania i dokładną wersję przed zwróceniem się o pomoc, aby można było odróżnić ten problem od problemu z duplikatami plików.