Automatyczna maszyna do zgrywania w ZimaOS: ograniczenia Dockera

Automatic Ripping Machine (ARM) można spakować i uruchomić jako aplikację Docker, ale nie oznacza to, że zgrywanie płyt optycznych będzie poprawnie działać w ZimaOS. Wątek społeczności IceWhale ze stycznia 2026 roku doprowadził dokładnie do takiego rozróżnienia: sam ARM działa w kontenerze, ale niezawodne zgrywanie płyt CD/DVD/Blu-ray wymaga wyjątkowo głębokiego dostępu do napędu optycznego i warstwy urządzeń Linuksa hosta.

Wątek nie doprowadził do potwierdzenia w pełni działającej konfiguracji ARM na ZimaOS. Jeden z uczestników zgłosił, że ARM nie działał poprawnie, a inny program do zgrywania w Dockerze generował błędy nieczytelnej płyty. Praktyczna rekomendacja społeczności polegała na zgrywaniu na drugim komputerze z systemem Linux i zapisywaniu gotowych plików w ZimaOS przez SMB lub NFS. Aktualna dokumentacja ARM potwierdza diagnozę techniczną: konfiguracja Dockera wymaga przekazywania urządzeń optycznych, urządzeń ogólnych SCSI, zgodnych identyfikatorów UID/GID hosta, a w niektórych konfiguracjach także trybu uprzywilejowanego i integracji z udev hosta.

Dlaczego zwykła aplikacja Docker nie wystarcza do zgrywania płyt

Większość aplikacji NAS potrzebuje tylko portów sieciowych i woluminów danych. Zgrywanie płyt optycznych wygląda inaczej, ponieważ oprogramowanie takie jak MakeMKV i ARM musi komunikować się bezpośrednio ze sprzętem napędu.

Typowe urządzenia optyczne w systemie Linux obejmują:

Dokumentacja ARM wyraźnie ostrzega, że MakeMKV może nie wykryć napędu lub nie móc go odczytać, jeśli przekazano tylko
/dev/sg1

Element /dev/sr* urządzenie udostępnia napęd optyczny, podczas gdy odpowiadające mu /dev/sg* Do poleceń niskiego poziomu może być wymagane urządzenie ogólne SCSI. Jeśli kontener otrzyma tylko zwykłe podpięcie folderu, nie będzie mógł wykonywać tych operacji.

Objawy zgłoszone w wątku dotyczącym ZimaOS

Użytkownik społeczności zgłosił:

ARM nie uruchamiał się poprawnie;
inny program do zgrywania działający w Dockerze uruchamiał się tylko w ograniczonej konfiguracji;
syslog-ng napotkał problemy z gniazdami lub uprawnieniami;
zgrywanie powodowało błędy nieczytelnej płyty, nawet gdy uznawano, że fizyczna płyta jest sprawna.

Inna odpowiedź wyjaśniała, że objawy te były zgodne z niepełnym dostępem do Dokumentacja ARM wyraźnie ostrzega, że MakeMKV może nie wykryć napędu lub nie móc go odczytać, jeśli przekazano tylko, przekazywania SCSI, zdarzeń udev lub innych uprawnień na poziomie hosta.

Aktualna dokumentacja ARM potwierdza wymagania sprzętowe

Aktualna dokumentacja ARM dotycząca Dockera instruuje użytkowników, aby sprawdzili urządzenia optyczne za pomocą:

lsscsi -g

Napęd może być przedstawiony na przykład tak:

CD/DVD ... /dev/sr0 /dev/sg1

ARM zaleca następnie przekazanie obu urządzeń do kontenera:

--device="/dev/sr0:/dev/sr0"
--device="/dev/sg1:/dev/sg1"

Zobacz aktualną dokumentację ARM dotyczącą Dockera.

ARM może również wymagać uprzywilejowanego dostępu do kontenera

Aktualny przewodnik ARM dotyczący kompilacji Dockera ze źródeł zawiera następującą informację:

--privileged

a jego dokumentacja rozwiązywania problemów wskazuje, że niektórzy użytkownicy potrzebują trybu uprzywilejowanego, aby wkładanie płyt i zgrywanie oparte na udev działały w pełni.

This is a major difference from ordinary media-server containers. Privileged mode gives a container broad host-device capabilities, so it should not be enabled casually on an untrusted image.

To istotna różnica w porównaniu ze zwykłymi kontenerami serwerów multimediów. Tryb uprzywilejowany zapewnia kontenerowi szerokie możliwości dostępu do urządzeń hosta, dlatego nie należy go włączać bez namysłu w przypadku niezaufanego obrazu.

Automatyzacja po włożeniu płyty zależy od hosta

ARM został zaprojektowany tak, aby automatycznie reagować po włożeniu płyty. Dokumentacja Dockera wymaga konfiguracji napędu po stronie hosta oraz działania udev, aby włożenie płyty mogło uruchomić przepływ zgrywania.

Przewodnik ARM dotyczący rozwiązywania problemów sugeruje sprawdzenie logów hosta pod kątem zdarzenia włożenia płyty i potwierdza, że kontener może działać prawidłowo, a automatyczne zgrywanie nadal może kończyć się niepowodzeniem, jeśli integracja udev na hoście nie działa.

Aktualne źródło: Rozwiązywanie problemów z ARM Docker.

Dlaczego MakeMKV może nie działać, nawet gdy ARM widzi napęd Dokumentacja ARM wyraźnie ostrzega, że MakeMKV może nie wykryć napędu lub nie móc go odczytać, jeśli przekazano tylko jest przekazywany, a odpowiadające mu urządzenie ogólnego przeznaczenia SCSI jest pomijane.

To sprawia, że objaw „nieczytelnej płyty” z dyskusji o ZimaOS jest szczególnie istotny. Odczytywalny napęd optyczny na hoście nie dowodzi, że kontener ma dostęp do wszystkich interfejsów urządzeń wymaganych przez MakeMKV.

ARM wymaga również zgodnych uprawnień hosta

Aktualna dokumentacja ARM zaleca utworzenie arm użytkownika/grupy na hoście i dopasowanie wartości w kontenerze:

ARM_UID
ARM_GID

z tym kontem hosta. Katalogi multimediów, konfiguracji, muzyki i logów muszą być zapisywalne przez tę tożsamość.

Jeśli identyfikatory się nie zgadzają, ARM może zakończyć działanie, zanim przepływ zgrywania dotrze w ogóle do napędu optycznego.

Co wątek źródłowy faktycznie potwierdza na temat ZimaOS

Dyskusja źródłowa nie potwierdza, że ARM na zawsze nie będzie możliwy w ZimaOS. Potwierdza, że w styczniu 2026 roku uczestnicy nie mieli zweryfikowanej konfiguracji, która skutecznie udostępniałaby wszystkie wymagane uprawnienia napędu optycznego.

Jeden z uczestników uznał, że głównym ograniczeniem był poziom dostępu do sprzętu i urządzeń dostępny dla kontenera. Pierwotny autor zaakceptował praktyczne rozwiązanie polegające na użyciu drugiego komputera do zgrywania.

Nie przekształcaj tego wyniku w ogólne stwierdzenie, że Docker nie może zgrywać płyt ani że ZimaOS nigdy nie będzie obsługiwać ARM.

Praktyczne rozwiązanie społeczności

Ostateczny plan zaakceptowany przez pierwotnego autora był następujący:

Zainstaluj ARM na innym komputerze z systemem Linux, który ma bezpośredni dostęp do napędu optycznego.
Zgraj i transkoduj płytę na tym komputerze.
Zapisz lub przenieś ukończone pliki do pamięci masowej ZimaOS.

Miejscem docelowym może być zamontowany udział SMB lub NFS, a pliki można też przesłać po zgraniu.

Dzięki temu ZimaOS pozostaje skoncentrowany na pamięci masowej i udostępnianiu multimediów, podczas gdy drugi komputer obsługuje niskopoziomowy sprzęt optyczny.

ARM oficjalnie obsługuje przepływy pracy z wyjściem opartym na zasobach sieciowych

Dokumentacja ARM dotycząca Dockera wskazuje, że woluminy wyjściowe mogą wskazywać udziały sieciowe, ale wydajność zależy od sieci i sposobu montowania.

Typowa architektura wygląda następująco:

Napęd optyczny
     ↓
Komputer z systemem Linux ARM
     ↓
Lokalna tymczasowa pamięć robocza
     ↓
Ukończone zgranie
     ↓
Biblioteka multimediów SMB/NFS ZimaOS

Korzystanie z szybkiej lokalnej pamięci tymczasowej na etapie zgrywania/transkodowania i przenoszenie na NAS tylko ukończonych plików może ograniczyć problemy z siecią i blokadami.

Jeśli nadal chcesz przetestować ARM bezpośrednio na ZimaOS

Przed próbą utworzenia niestandardowej aplikacji zbierz informacje o urządzeniach hosta:

lsscsi -g
ls -l /dev/sr*
ls -l /dev/sg*

Następnie sprawdź, czy niestandardowa konfiguracja Dockera w ZimaOS może odzwierciedlać wszystkie wymagania udokumentowane przez ARM:

urządzenie optyczne /dev/sr* urządzenie;
odpowiadające mu /dev/sg* urządzenie;
wymagane uprawnienia hosta/kontenera;
trwałe woluminy konfiguracji, dzienników, muzyki i multimediów;
tryb uprzywilejowany lub równoważne uprawnienia, jeśli są wymagane;
mechanizm obsługi zdarzeń hosta/udev używany do automatycznego zgrywania.

Jeśli ZimaOS nie może udostępnić któregoś z tych wymagań w ramach obecnego modelu aplikacji, zmiana zwykłych ścieżek woluminów Dockera nie rozwiąże problemu ze zgrywaniem.

Uwagi dotyczące bezpieczeństwa i niezawodności

Kontenery uprzywilejowane otrzymują szeroki dostęp do hosta. Używaj wyłącznie zaufanych obrazów i miej świadomość związanego z tym ryzyka.
Nie przekazuj do ARM niezwiązanych urządzeń hosta.
Nadaj ARM dostęp do zapisu wyłącznie do katalogów, których potrzebuje.
Użyj dedykowanego katalogu roboczego z wystarczającą ilością wolnego miejsca; zgrywanie płyt optycznych i transkodowanie mogą tymczasowo wymagać znacznej ilości pamięci masowej.
Twórz niezależne kopie zapasowe ukończonych materiałów, niezależnie od procesu zgrywania.

Lista kontrolna ARM na ZimaOS

Potwierdź, że napęd optyczny jest widoczny na hoście ZimaOS.
Uruchom lsscsi -g i zidentyfikuj oba /dev/sr* oraz /dev/sg*.
Porównaj możliwości niestandardowych aplikacji ZimaOS z aktualnymi wymaganiami ARM dotyczącymi Dockera.
Dopasuj ARM_UID/ARM_GID do zapisywalnych katalogów hosta.
Sprawdź, czy dostępny jest tryb uprzywilejowany i integracja ze zdarzeniami hosta.
Nie zakładaj, że działający interfejs WebUI ARM oznacza, iż MakeMKV ma prawidłowy dostęp do napędu.
Jeśli przekazywanie urządzenia nadal działa zawodnie, użyj osobnego komputera do zgrywania i zapisuj ukończone pliki na ZimaOS.

Najczęściej zadawane pytania dotyczące Automatic Ripping Machine na ZimaOS

Czy można zainstalować ARM na ZimaOS?

Można uruchomić go w kontenerze, ale wątek źródłowy nie potwierdził w pełni działającej konfiguracji zgrywania na ZimaOS, ponieważ problemem blokującym było przekazanie napędu optycznego i uprawnienia.

Dlaczego program do zgrywania informuje, że płyta jest nieczytelna?

Jedną z możliwych przyczyn jest niepełne przekazanie urządzenia. Aktualna dokumentacja ARM wskazuje, że MakeMKV może wymagać zarówno urządzenia optycznego, /dev/sr* urządzenie i odpowiadające mu urządzenie ogólnego przeznaczenia SCSI /dev/sg* urządzenie.

Czy ARM wymaga trybu uprzywilejowanego?

Aktualna dokumentacja ARM dotycząca Dockera uwzględnia tryb uprzywilejowany w instrukcjach konfiguracji i rozwiązywania problemów dla niektórych konfiguracji. To, czy jest on wymagany w każdej instalacji, zależy od hosta i sposobu pracy z urządzeniem.

Jakie rozwiązanie zostało zaakceptowane w wątku źródłowym?

Autor oryginału zdecydował się zainstalować ARM na drugim komputerze i przenieść zgrane pliki do pamięci masowej na serwerze ZimaOS.