Varför försvinner åtkomsten till maskinvarutranskodning efter en containeruppdatering?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why Does Hardware Transcoding Access Disappear After a Container Update?

Hårdvarutranskodning försvinner vanligtvis efter en uppdatering eftersom den återskapade containern inte längre ser samma enhet, behörighetsgrupp eller körtidsfunktion och inte heller har en kompatibel userspace-stack.

Värddatorns GPU kan fortfarande fungera medan Plex, Jellyfin, Emby eller en kameraapp i tysthet växlar tillbaka till CPU efter att avbildningen har ersatts. Börja med att bekräfta om enheten finns i den nya containern och om dess tjänsteanvändare kan öppna den. Separera sedan problem med körtidsmappning och behörigheter från en bildspecifik regression i kodek eller drivrutin.

Bekräfta att arbetsbelastningen verkligen har växlat tillbaka till programvara

Tvinga fram en fil som kräver omkodning och dokumentera medieserverns instrumentpanel, FFmpeg- eller omkodningsloggen, CPU-användningen på värddatorn och GPU-motoraktiviteten. Direktuppspelning testar inte hårdvaruvägen.

Ett fall i LinuxServer-communityt rekommenderar att kontrollera en uttrycklig hårdvaruindikator och GPU-telemetri, eftersom enbart CPU-aktivitet kan vara missvisande. Den användbara skiljelinjen är aktiv GPU-motoranvändning under en kontrollerad omkodning.

Om loggarna visar att hårdvarukodaren öppnas korrekt bör du undersöka filter, undertexter, tonmappning eller partiell acceleration som inte stöds. Om enheten inte kan öppnas fortsätter du med detektering på värddatorn och åtkomst från containern.

Jämför GPU-enheter på värddatorn och i containern

Lista de förväntade enhetsnoderna på värddatorn och i den uppdaterade containern. För Intel eller AMD VA-API jämför du /dev/dri/card* och /dev/dri/renderD*. För NVIDIA jämför du synligheten i körtidsmiljön och de enheter som rapporteras av dess hanteringsverktyg.

Ett Unraid Quick Sync-fall visar att värddatorn kan behöva rätt kärnmodul innan /dev/dri finns, och att containern fortfarande behöver få den enheten vidarebefordrad. Den saknade gränsen är ofta mappningen av /dev/dri-enheten snarare än mediebiblioteket eller appdatabasen.

Om enheten saknas på värddatorn ska du först åtgärda värddatorns drivrutin, BIOS, kärna eller maskinvarustatus. Om den finns på värddatorn men inte i containern jämför du den gamla och nya Compose-konfigurationen eller den enhetskonfiguration som genererats av gränssnittet.

Verifiera åtkomst till render- och videogruppen

Dokumentera det numeriska ägar- och grupp-ID:t för GPU-enhetsnoderna på värddatorn och kontrollera sedan vilka grupper tjänsteanvändaren tillhör i containern. Namn som render kan motsvara olika numeriska ID:n i olika avbildningar.

Ett felsökningsfall med Jellyfin Docker visar en fungerande konfiguration som uttryckligen matchar värddatorns ID för render-gruppen och kontrollerar behörigheterna för renderD128. Den numeriska render-gruppsmappningen kan ändras när en avbildning ändrar sina interna användare eller grupper.

Lägg till den nödvändiga kompletterande gruppen i containerdefinitionen i stället för att göra enheten skrivbar för alla. Återskapa containern och testa åtkomsten som den faktiska medietjänsteanvändaren.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Kontrollera körtidsflaggor och bildspecifika funktioner

Jämför definitionerna för den tidigare och aktuella avbildningen med avseende på devices, group_add, GPU-körtidsinställningar, variabler för GPU-funktioner, privilegierat läge och eventuella ändringar i containerhanterarens mall.

En rapport om Emby beskriver hur hårdvaruacceleration slutade fungera i Docker medan appen fortfarande var tillgänglig. Den illustrerar programvaruåtergången efter GPU-förlust som gör problemet lätt att missa.

Lös inte ett avgränsat åtkomstproblem för en enhet genom att ge breda privilegier. Återställ de minsta enhets- och gruppbehörigheter som krävs av kodningsvägen.

Skilj en regression i containeravbildningen från ett fel på värddatorn

Kör ett enkelt GPU- eller FFmpeg-test i den uppdaterade containern och jämför sedan med den tidigare låsta avbildningen med samma monteringar, enhetsmappningar, mediefil och appkonfiguration.

Om den gamla avbildningen fungerar omedelbart och den nya misslyckas med identiskt körtidsläge bör du spara loggarna och behandla uppdateringen som en regression i userspace, kodek, FFmpeg eller applikationen. Skriv inte om behörigheterna upprepade gånger när den kontrollerade bildjämförelsen redan har isolerat versionen.

Rensa endast dokumenterade återskapningsbara kodekcacher när loggarna pekar på dem, och låt appdatabasen och mediemetadata vara orörda. Lås fast den kända fungerande avbildningen tills regressionen är förstådd eller åtgärdad.

Validera hela kedjan efter reparationen

Testa hårdvaruavkodning, kodning, tonmappning, inbränning av undertexter och minst en klient som tvingar fram omkodning. Bekräfta att den förväntade GPU-enheten visas i loggarna och att värddatorn visar ihållande motoraktivitet.

ZimaSpaces procedur för verifiering av verklig hårdvarutranskodning ger ett bättre slutförandetest än en växel på inställningssidan.

Problemet är åtgärdat först när den uppdaterade eller låsta containern behåller åtkomsten till enheten efter återskapande och omstart, använder GPU:n för den avsedda kodekvägen och inte längre växlar tillbaka i tysthet. Behåll den tidigare avbildningens digest och körtidsdefinition som återställningsgräns inför nästa uppdatering.