Czy Jellyfin może działać na ARM i x86 z tymi samymi danymi?

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 Run on ARM and x86 With the Same Data? - Zima Store Online

Zazwyczaj tak, ale traktuj migrację z ARM na x86 jako kontrolowaną migrację hosta, a nie dowód na to, że każdy komponent Jellyfin jest niezależny od architektury. W przypadku aktualnych wydań Jellyfin właściwym celem ARM jest ARM64; miejsce docelowe x86 również powinno być obsługiwaną platformą 64-bitową. Zachowaj źródło w niezmienionym stanie, dopóki miejsce docelowe nie przejdzie testów ponownego uruchomienia i odtwarzania.

Kluczowa granica dotyczy kwestii operacyjnych: zatrzymaj źródło przed skopiowaniem trwałego stanu i nigdy nie pozwalaj, aby dwie instancje Jellyfin na różnych hostach zapisywały dane do tego samego aktywnego katalogu. Jellyfin nie opisuje migracji z ARM64 do x86-64 jako specjalnej ścieżki migracji bez ryzyka, dlatego zachowaj kopię umożliwiającą wycofanie zmian i osobno odtwórz elementy zależne od platformy, takie jak pakiety FFmpeg, mapowania urządzeń akceleracji sprzętowej, natywne zależności wtyczek, uprawnienia i ścieżki hosta.

Sprawdź, czy architektura miejsca docelowego jest rzeczywiście obsługiwana

Najpierw potwierdź, że miejsce docelowe jest obecnie obsługiwaną 64-bitową platformą Jellyfin. Nie zakładaj, że starsza płytka ARM, 32-bitowy system operacyjny lub zabytkowy komputer x86 będzie odpowiedni tylko dlatego, że Linux nadal się na nim uruchamia.

Jellyfin 10.11 formalnie usunął obsługę ARM32, w tym armhf, i obecnie na platformach ARM wymaga 64-bitowego systemu operacyjnego ARM64. Jeśli źródło nadal korzysta ze starszej 32-bitowej kompilacji ARM, najpierw zaplanuj obsługiwane 64-bitowe miejsce docelowe, zamiast traktować stare środowisko uruchomieniowe jako aktualny cel migracji.

W przypadku x86 użyj obsługiwanego hosta x86-64, który spełnia wymagania wersji Jellyfin, którą zamierzasz uruchomić. Jeśli miejsce docelowe zależy od nieoficjalnego pakietu, nieobsługiwanego systemu operacyjnego lub przestarzałego procesora, rozwiąż ten problem platformy przed przeniesieniem trwałego stanu.

Traktuj zapisany stan jako przenośny, ale wdrożenie jako zależne od platformy

Standardowe wdrożenie Jellyfin przechowuje trwały stan serwera w bazie danych wraz z plikami konfiguracji i metadanych. W przypadku instalacji korzystających z SQLite format bazy danych na dysku został zaprojektowany z myślą o przenośności między architekturami procesorów, więc sama rodzina procesora nie jest powodem, aby przed migracją konwertować bazę danych bajt po bajcie.

SQLite opisuje swój format plików jako wieloplatformowy format bazy danych, zapewniający między innymi przenośność między systemami 32- i 64-bitowymi oraz systemami o różnej kolejności bajtów. Potwierdza to przenośność formatu bazy danych, ale nie gwarantuje, że każda wtyczka Jellyfin, zewnętrzny plik wykonywalny, sterownik lub ścieżka właściwa dla danego wdrożenia zadziała bez zmian.

Pamiętaj o tym rozróżnieniu: przenośne zapisane rekordy to tylko jedna warstwa. O tym, czy miejsce docelowe będzie działać jak źródło, decydują również zgodność wersji Jellyfin, kompletność danych i konfiguracji, spójność ścieżek multimediów, zależności wtyczek, uprawnienia oraz dostęp do urządzeń sprzętowych.

Zatrzymaj Jellyfin przed przeniesieniem aktywnego stanu

W przypadku kontrolowanej migracji architektury zamknij proces Jellyfin na źródle przed utworzeniem kopii migracyjnej. Zapobiega to zmianom w aktywnej bazie danych lub stanie zapisu z wyprzedzeniem podczas kopiowania plików i zapewnia jeden spójny punkt wycofania zmian.

Skopiuj cały zakres danych i konfiguracji, zamiast wybierać tylko jellyfin.db. Częściowa kopia może zachować użytkowników, ale utracić konfigurację, wtyczki, metadane lub inne elementy stanu oczekiwane przez miejsce docelowe.

Ten sam model ochrony stosowany w planie tworzenia kopii zapasowych 3-2-1 ma zastosowanie również tutaj: zachowaj źródło w niezmienionym stanie, dopóki miejsce docelowe nie przejdzie rzeczywistego testu przywracania i odtwarzania.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Odtwórz elementy zależne od architektury na nowym hoście

Zainstaluj natywny pakiet Jellyfin dla miejsca docelowego albo użyj właściwego wieloarchitekturowego obrazu kontenera. Odtwórz mapowania urządzeń GPU, uprawnienia grup, pakiety FFmpeg i wszystkie ścieżki właściwe dla hosta, zamiast kopiować pliki binarne ze starej architektury.

Po pierwszym uruchomieniu sprawdź wtyczki. Wtyczki zależne od bibliotek natywnych, dołączonych plików binarnych lub zewnętrznych plików wykonywalnych mogą wymagać kompilacji zgodnej z nową architekturą. Jeśli problematyczna wtyczka uniemożliwia uruchomienie, wyłącz ją podczas pierwszej walidacji, a następnie dodaj ponownie dopiero po potwierdzeniu zgodności.

Jeśli ścieżki multimediów różnią się między hostami, w miarę możliwości zachowaj te same ścieżki za pomocą montowań. W przeciwnym razie zaplanuj obsługiwaną migrację ścieżek zamiast ręcznie edytować wewnętrzne rekordy bazy danych Jellyfin.

Zweryfikuj migrację, zanim ponownie użyjesz źródła

Uruchom wyłącznie instancję w miejscu docelowym i potwierdź obecność użytkowników, bibliotek, stanu oglądania, grafik, zaplanowanych zadań oraz jednego odtwarzania bezpośredniego i jednego wymaganego transkodowania. Sprawdź dzienniki pod kątem brakujących bibliotek natywnych, błędów uprawnień lub ścieżek nadal wskazujących na stary host.

Uruchom ponownie miejsce docelowe dwa razy i powtórz test odtwarzania, aby upewnić się, że powodzenie jest trwałe, a nie wynika z jednorazowego uruchomienia. Jeśli miejsce docelowe zawiedzie, zatrzymaj je i przywróć kopię migracyjną albo wróć do niezmienionego źródła, zamiast pozwalać obu instancjom zapisywać ten sam stan.

Migracja jest zakończona dopiero wtedy, gdy nowy host przetrwa ponowne uruchomienie i normalne użytkowanie domowe. Jeśli chcesz zachować stary komputer jako zapas, użyj na nim osobnej przywróconej kopii albo pozostaw go wyłączonego; nie używaj jednego aktywnego katalogu danych Jellyfin jako współdzielonej pamięci między serwerami ARM i x86.