Dlaczego dostęp do sprzętowego transkodowania znika po aktualizacji kontenera?

Sprzętowe transkodowanie zwykle znika po aktualizacji, ponieważ odtworzony kontener nie ma już dostępu do tego samego urządzenia, grupy uprawnień, możliwości środowiska uruchomieniowego lub zgodnego stosu przestrzeni użytkownika.

GPU hosta może nadal działać, podczas gdy Plex, Jellyfin, Emby lub aplikacja kamerowa po cichu przełącza się na procesor po zastąpieniu obrazu. Najpierw trzeba sprawdzić, czy urządzenie jest widoczne w nowym kontenerze i czy jego użytkownik usługowy może je otworzyć, a następnie oddzielić mapowanie środowiska uruchomieniowego i uprawnienia od regresji kodeka lub sterownika specyficznej dla obrazu.

Potwierdź, że obciążenie rzeczywiście przełączyło się na oprogramowanie

Wymuś plik wymagający transkodowania i zapisz informacje z panelu serwera multimediów, dziennika FFmpeg lub transkodera, użycie procesora hosta oraz aktywność silnika GPU. Odtwarzanie bezpośrednie nie sprawdza ścieżki sprzętowej.

Przypadek opisany w społeczności LinuxServer zaleca sprawdzenie wyraźnego wskaźnika sprzętowego i telemetrii GPU, ponieważ sama aktywność procesora może wprowadzać w błąd. Najlepszym wskaźnikiem jest aktywność silnika GPU podczas kontrolowanego transkodowania.

Jeśli dzienniki pokazują pomyślne otwarcie sprzętowego kodera, sprawdź nieobsługiwane filtry, napisy, mapowanie tonów lub częściowe przyspieszenie. Jeśli urządzenia nie można otworzyć, przejdź do wykrywania hosta i dostępu kontenera.

Porównaj urządzenia GPU na hoście i w kontenerze

Wyświetl oczekiwane węzły urządzeń na hoście i wewnątrz zaktualizowanego kontenera. W przypadku VA-API firmy Intel lub AMD porównaj /dev/dri/card* oraz /dev/dri/renderD*; w przypadku NVIDIA porównaj widoczność środowiska uruchomieniowego i urządzenia zgłaszane przez jej narzędzie zarządzające.

Przypadek Quick Sync w Unraid pokazuje, że host może wymagać właściwego modułu jądra, zanim pojawi się /dev/dri, a kontener nadal musi mieć przekazane to urządzenie. Brakującym elementem jest często mapowanie urządzenia /dev/dri, a nie biblioteka multimediów ani baza danych aplikacji.

Jeśli urządzenia nie ma na hoście, najpierw napraw sterownik hosta, ustawienia BIOS-u, jądro lub stan sprzętu. Jeśli jest na hoście, ale nie ma go w kontenerze, porównaj konfigurację urządzeń w poprzednim i nowym pliku compose lub wygenerowaną przez interfejs użytkownika.

Sprawdź dostęp do grup renderowania i wideo

Zapisz numeryczne identyfikatory właściciela i grupy węzłów urządzeń GPU na hoście, a następnie sprawdź grupy przypisane użytkownikowi usługowemu w kontenerze. Nazwy takie jak render mogą odpowiadać różnym identyfikatorom numerycznym w zależności od obrazu.

Przypadek dotyczący rozwiązywania problemów z Jellyfin w Dockerze pokazuje działającą konfigurację, która jawnie dopasowuje identyfikator grupy renderowania hosta i sprawdza uprawnienia renderD128. To numeryczne mapowanie grupy renderowania może się zmienić, gdy obraz zmieni wewnętrznych użytkowników lub grupy.

Dodaj wymaganą grupę uzupełniającą w definicji kontenera zamiast udostępniać urządzenie wszystkim użytkownikom. Odtwórz kontener i przetestuj dostęp jako rzeczywisty użytkownik usługi multimedialnej.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sprawdź flagi środowiska uruchomieniowego i możliwości specyficzne dla obrazu

Porównaj poprzednią i bieżącą definicję obrazu pod kątem devices, group_add, ustawień środowiska uruchomieniowego GPU, zmiennych możliwości, trybu uprzywilejowanego oraz wszelkich zmian szablonu menedżera kontenerów.

Raport dotyczący Emby opisuje zatrzymanie sprzętowego przyspieszenia w Dockerze przy zachowaniu dostępności aplikacji, ilustrując przełączenie na oprogramowanie po utracie GPU, przez które łatwo przeoczyć ten problem.

Nie rozwiązuj wąskiego problemu z dostępem do urządzenia, przyznając szeroki dostęp uprzywilejowany. Przywróć tylko minimalne uprawnienia do urządzenia i grupy wymagane przez ścieżkę kodera.

Oddziel regresję obrazu kontenera od awarii hosta

Uruchom prosty test GPU lub FFmpeg w zaktualizowanym kontenerze, a następnie porównaj go z poprzednim przypiętym obrazem, używając tych samych punktów montowania, mapowań urządzeń, pliku multimedialnego i konfiguracji aplikacji.

Jeśli stary obraz działa natychmiast, a nowy zawodzi przy identycznym stanie środowiska uruchomieniowego, zachowaj dzienniki i potraktuj aktualizację jako regresję przestrzeni użytkownika, kodeka, FFmpeg lub aplikacji. Nie zmieniaj wielokrotnie uprawnień, gdy kontrolowane porównanie obrazów już wskazuje konkretną wersję.

Usuwaj tylko udokumentowane, możliwe do odtworzenia pamięci podręczne kodeków, gdy dzienniki wskazują na ten problem, i pozostaw bazę danych aplikacji oraz metadane multimediów bez zmian. Przypnij znany, działający obraz do czasu wyjaśnienia lub naprawienia regresji.

Zweryfikuj cały potok po naprawie

Przetestuj sprzętowe dekodowanie, kodowanie, mapowanie tonów, wypalanie napisów oraz co najmniej jednego klienta wymuszającego transkodowanie. Potwierdź, że oczekiwane urządzenie GPU pojawia się w dziennikach, a host pokazuje stałą aktywność silnika.

Procedura ZimaSpace dotycząca weryfikacji rzeczywistego sprzętowego transkodowania zapewnia lepszy test końcowy niż przełącznik na stronie ustawień.

Problem jest rozwiązany dopiero wtedy, gdy zaktualizowany lub przypięty kontener zachowuje dostęp do urządzenia po odtworzeniu i ponownym uruchomieniu, korzysta z GPU dla zamierzonej ścieżki kodeka i nie przełącza się już po cichu na oprogramowanie. Zachowaj skrót poprzedniego obrazu oraz definicję środowiska uruchomieniowego jako punkt przywracania na potrzeby kolejnej aktualizacji.