Deze communitytip beschrijft een zeer specifieke fout met externe opslag: de NVMe-schijf werd normaal aangekoppeld, Plex kon media afspelen en vervolgens verdween de koppeling na ongeveer tien minuten inactiviteit. Opnieuw aansluiten of handmatig opnieuw koppelen herstelde de toegang.
De belangrijkste les is niet simpelweg: ‘gebruik geen exFAT’. De thread wijst op drie afzonderlijke lagen die een vergelijkbaar Plex-symptoom kunnen veroorzaken: slaapstand van de firmware van de behuizing, USB-autosuspend in Linux en herstelgedrag van het bestandssysteem en de koppeling.
De melding ‘Bestand niet gevonden’ in Plex kan onder Plex beginnen
Plex kent alleen de bibliotheekmap die eraan is toegewezen. Voor het aanmaken van een Plex-bibliotheek volgens het officiële aanmaken van een Plex-bibliotheek moet de mediamap toegankelijk blijven voor de server. Als de USB-bridge de verbinding verbreekt en het koppelpunt verdwijnt, meldt Plex dat media ontbreekt omdat het onderliggende opslagpad niet langer bestaat.
De handleiding voor een NAS-mediacenter is nuttig voor de normale Plex-architectuur van ZimaOS, terwijl de hardwarevereisten voor Plex de vereisten voor de werklast van een mediaserver onderscheiden van die van een opslagbehuizing die de verbinding verbreekt.
Slaapstand van de behuizing en Linux-autosuspend zijn verschillend
De auteur van de bron meldde dat de ORICO-behuizing zelf na een periode van inactiviteit een ‘intelligente slaapstand’ activeerde. Linux heeft daarnaast een eigen, onafhankelijke laag voor USB-energiebeheer. De documentatie over USB-energiebeheer in Linux legt uit dat power/control=auto USB-autosuspend toestaat, terwijl on door de kernel geïnitieerde autosuspend voor dat apparaat voorkomt.
Het uitschakelen van Linux-autosuspend kan daarom geen oplossing garanderen als de firmware van de behuizing zelf een harde slaapstand afdwingt. Gebruik dit als isolatietest, niet als bewijs dat de USB-bridge gezond is.
Waarom ext4 stabieler kan lijken dan exFAT
In de thread werd gemeld dat ext4 zich beter herstelde dan exFAT, maar er werden geen gecontroleerde tests beschreven die bewijzen dat exFAT de verbinding veroorzaakte. Beschouw de keuze van het bestandssysteem als één variabele, nadat de fysieke USB-bridge en het slaapgedrag zijn begrepen.
Als de schijf ook door containers moet worden gebruikt, legt de workflow voor het koppelen van een externe schijf uit waarom er eerst een stabiel koppelpunt op de host moet bestaan voordat een toepassing op dat pad kan vertrouwen.
Een veiligere volgorde voor probleemoplossing
- Controleer of het volledige USB-apparaat verdwijnt of dat alleen Plex de bibliotheek kwijtraakt.
- Controleer of het koppelpunt na de periode van inactiviteit nog bestaat.
- Test USB-autosuspend in Linux afzonderlijk van slaapstand op behuizingsniveau.
- Test ext4 tegenover exFAT pas nadat het ontwaakgedrag van de hardware is begrepen.
- Geef voor een mediabibliotheek die altijd beschikbaar moet zijn de voorkeur aan een behuizing die onder Linux betrouwbaar uit de slaapstand komt.
Kort samengevat
De communitycase kan het best worden begrepen als een probleem met het ontwaken en hervatten van de behuizing, dat zich uitte als een fout in de Plex-bibliotheek. exFAT kan het herstel minder betrouwbaar hebben gemaakt, maar het wijzigen van het bestandssysteem kan slaapstand op firmwareniveau niet uitschakelen. Geef voor een ZimaOS-mediaserver die altijd beschikbaar moet zijn prioriteit aan een USB/NVMe-bridge die na perioden van inactiviteit stabiel blijft.
