Intermitterende Plex-fouten met meerdere clients zijn meestal te diagnosticeren door te kijken welke stream als eerste verandert: transcodering, bandbreedte, opslag-I/O of één clientspecifiek pad.
Een server die stabiel is voor één tv kan alsnog uitvallen wanneer een telefoon, externe browser en smart-tv tegelijkertijd verschillende bestanden starten. De clients vragen mogelijk niet dezelfde werklast: de ene kan Direct Play gebruiken, terwijl een andere een videotranscodering afdwingt, ondertitels inbrandt of via het WAN verbinding maakt. Reproduceer de fout door clients één voor één toe te voegen en gebruik het Plex-dashboard om vast te leggen wat elke sessie daadwerkelijk doet voordat je limieten of hardware wijzigt.
Stel een basislijn met één stream op voordat je gelijktijdigheid test
Begin met de combinatie van client en bestand die het vaakst faalt, maar gebruik slechts die ene stream. Noteer of Plex Direct Play, Direct Stream of Transcode meldt, en let op het gedrag van CPU, GPU, netwerk en schijf. Als de stream zelfstandig faalt, is gelijktijdigheid niet de primaire oorzaak en moet de rest van de test worden gestopt.
Plex legt uit dat de streamingcapaciteit van een server vooral wordt beperkt door processorvermogen en netwerkbandbreedte wanneer transcodering of afspelen op afstand een rol speelt. Dat onderscheid is belangrijk, omdat een server veel Direct Play-sessies kan verwerken, maar snel een limiet bereikt wanneer meerdere clients conversie aanvragen.
Als de basislijn goed is, voeg je een tweede client toe zonder de eerste te wijzigen. Ga door met één client per keer totdat de eerste waarneembare fout optreedt. De stream die je op het breekpunt toevoegt, is informatiever dan een willekeurige foutmelding, omdat die laat zien welke nieuwe werklast de serverstatus heeft veranderd.
Gebruik het dashboard om transcodeerdruk van netwerkdruk te onderscheiden
Wanneer de fout optreedt, inspecteer je elke actieve sessie in het dashboard. Als het foutmoment samenvalt met een nieuwe hardware- of softwaretranscodering, test je dezelfde client met een bestand dat compatibel is met Direct Play of met een minder complexe ondertitelroute. Als de fout verdwijnt, is de transcodeerpijplijn de meest waarschijnlijke oorzaak.
De handleiding voor hardwareversnelling van ZimaSpace helpt te begrijpen waarom meerdere streams werk van de CPU naar een beschikbare versneller kunnen verplaatsen en waarom de server toch voldoende marge nodig heeft voor andere NAS-taken. Hardwareversnelling bewijst geen onbeperkte gelijktijdigheid; het is slechts één bronpad dat je moet controleren.
Als alleen externe streams falen terwijl lokale sessies goed blijven werken, test je de werkelijke uploadsnelheid bij de server gedurende hetzelfde tijdvenster en vergelijk je die met de gecombineerde vraag van de streams. Als zowel lokale als externe clients tegelijk falen, zoek je verder in compute of opslag in plaats van de internetverbinding als gemeenschappelijke oorzaak aan te wijzen.
Controleer of de container of host verzadigd raakt op het foutmoment
Houd de Plex-container en host in de gaten terwijl je streams toevoegt. Een CPU-plafond, verzadiging van de video-engine van de GPU, geheugendruk of hoge I/O-wachttijd die bij hetzelfde aantal clients optreedt, is een sterkere aanwijzing dan het gemiddelde gebruik dat je na de fout waarneemt. Zoek naar de bron die als eerste zijn limiet bereikt.
De opdracht docker container stats kan tijdens de test het CPU-, geheugen-, netwerk- en blok-I/O-gebruik van de container tonen. Combineer dit met de sessieweergave van Plex, zodat je kunt vaststellen of de piek bij Plex hoort en welke actie van de client deze heeft veroorzaakt.
Als het resourcegebruik bescheiden blijft maar één client faalt, vervang je alleen die client of dat mediabestand. Een fout die één apparaat, codec, ondertitelindeling of netwerkpad volgt, hoort thuis in een specifiekere tak voor clientcompatibiliteit. Verlaag geen serverbrede limieten om een probleem op te lossen dat slechts door één eindpunt kan worden gereproduceerd.
Pas de kleinst mogelijke passende oplossing toe en test dezelfde clientmix opnieuw
Bij een bevestigde transcodeerlimiet verminder je onnodige transcodering, controleer je hardwareversnelling of stel je een bewuste limiet voor gelijktijdige transcoderingen in, zodat de NAS responsief blijft. Bij een bevestigde uploadbeperking stem je de kwaliteit van externe streams af of vergroot je de beschikbare uploadsnelheid. Bij opslag-I/O test je de mediapaden en tijdelijke transcodeerpaden afzonderlijk voordat je iets verplaatst.
Herhaal exact de clientvolgorde die oorspronkelijk faalde en laat deze lang genoeg draaien om het oude breekpunt te overschrijden. Een geslaagde oplossing betekent dat hetzelfde aantal en dezelfde mix van clients stabiel blijven onder dezelfde media-indelingen en dezelfde externe/lokale omstandigheden, niet alleen dat één testvideo succesvol start.
Als de fout zonder verband met resources blijft verschuiven, verzamel je Plex-serverlogboeken met tijdstempels voor het starten en falen van elke client. Escaleer met de modellen van de clients, versies van de Plex-apps, de serverversie, mediagegevens en de eerste stap met gelijktijdigheid waarop de fout optrad, zodat de volgende diagnose met reproduceerbaar bewijs begint.
Ondersteuning & Tips
Meer om te lezen

Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...

Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.

Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...

