Varför misslyckas Plex ibland när flera enheter streamar samtidigt?
Intermittenta Plex-fel med flera klienter blir vanligtvis möjliga att diagnostisera när du observerar vilken ström som förändras först: omkodning, bandbredd, lagrings-I/O eller en klientspecifik sökväg.
En server som är stabil för en TV kan ändå sluta fungera när en telefon, en fjärrwebbläsare och en smart-TV startar olika filer samtidigt. Klienterna kanske inte efterfrågar samma arbetsbelastning: en kan använda Direct Play medan en annan tvingar fram videoomkodning, bränner in undertexter eller går över WAN. Återskapa felet genom att lägga till klienter en i taget och använd Plex Dashboard för att dokumentera vad varje session faktiskt gör innan du ändrar begränsningar eller hårdvara.
Skapa en baslinje med en enda ström innan du testar samtidighet
Börja med den klient- och filkombination som oftast orsakar felet, men kör bara den strömmen. Dokumentera om Plex rapporterar Direct Play, Direct Stream eller Transcode, och notera CPU-, GPU-, nätverks- och diskbeteende. Om strömmen misslyckas på egen hand är samtidighet inte den främsta orsaken, och resten av testet bör avbrytas.
Plex förklarar att serverns streamingkapacitet främst begränsas av processorkraft och nätverksbandbredd när omkodning eller fjärruppspelning används. Den skillnaden är viktig eftersom en server kan hantera många Direct Play-sessioner men snabbt nå en gräns när flera klienter begär konvertering.
Om baslinjen är felfri lägger du till en andra klient utan att ändra den första. Fortsätt med en klient i taget tills det första observerbara felet uppstår. Strömmen du lägger till vid brytpunkten är mer informativ än ett slumpmässigt felmeddelande, eftersom den visar vilken nya arbetsbelastning som ändrade serverns tillstånd.
Använd Dashboard för att skilja mellan omkodningsbelastning och nätverksbelastning
När felet uppstår granskar du alla aktiva sessioner i Dashboard. Om felet sammanfaller med en ny hårdvaru- eller mjukvaruomkodning testar du samma klient med en fil som är kompatibel med Direct Play eller med en undertextlösning med lägre komplexitet. Om felet försvinner är omkodningskedjan den mest sannolika orsaken.
ZimaSpaces guide till hårdvaruacceleration är användbar för att förstå varför flera strömmar kan flytta arbete från CPU:n till en tillgänglig accelerator och varför servern fortfarande behöver marginal för andra NAS-uppgifter. Hårdvaruacceleration är inget bevis på obegränsad samtidighet; det är en resursväg som måste verifieras.
Om endast fjärrströmmar misslyckas medan lokala sessioner förblir stabila testar du den faktiska uppladdningsbandbredden vid servern under samma tidsperiod och jämför den med den sammanlagda strömbelastningen. Om både lokala och fjärranslutna klienter misslyckas samtidigt fortsätter du att undersöka beräkning eller lagring i stället för att behandla internetanslutningen som den gemensamma orsaken.
Kontrollera om containern eller värden når taket vid brytpunkten
Övervaka Plex-containern och värden medan du lägger till strömmar. Ett CPU-tak, mättnad i GPU:ns videoenhet, minnestryck eller hög I/O-wait som uppstår vid samma antal klienter är en starkare ledtråd än genomsnittlig användning som observeras efter felet. Leta efter den resurs som först når sin gräns.
Dockers kommando för containerstatistik kan visa containerns CPU-, minnes-, nätverks- och block-I/O-användning medan testet körs. Kombinera detta med Plex sessionvy så att du kan avgöra om resursökningen kommer från Plex och vilken klientåtgärd som utlöste den.
Om resursanvändningen förblir måttlig men en klient misslyckas byter du endast ut den klienten eller mediefilen. Ett fel som följer en viss enhet, codec, undertextformat eller nätverkssökväg hör hemma i en snävare gren för klientkompatibilitet. Sänk inte serveromfattande begränsningar för att lösa ett problem som bara kan återskapas av en enda slutpunkt.
Tillämpa den minsta matchande åtgärden och testa samma klientmix igen
Vid en bekräftad omkodningsbegränsning minskar du onödig omkodning, verifierar hårdvaruacceleration eller anger en avsiktlig gräns för samtidiga omkodningar som lämnar NAS-enheten responsiv. Vid en bekräftad uppladdningsbegränsning justerar du kvaliteten på fjärrströmmar eller ökar den tillgängliga uppladdningsbandbredden. Vid lagrings-I/O testar du medie- och temporära omkodningssökvägarna separat innan du flyttar något.
Upprepa exakt den klientsekvens som ursprungligen orsakade felet och låt den köras tillräckligt länge för att passera den tidigare brytpunkten. En lyckad åtgärd innebär att samma antal och kombination av klienter förblir stabila med samma medieformat och samma fjärranslutna/lokala förhållanden, inte bara att en enskild testvideo börjar spela upp utan problem.
Om felet fortfarande flyttar sig utan någon koppling till resursanvändningen samlar du in Plex-serverloggar med tidsstämplar för varje klientstart och fel. Eskalera med klientmodeller, Plex-appversioner, serverversion, mediedetaljer och det första steget där samtidigheten orsakade fel, så att nästa felsökning kan börja med reproducerbara bevis.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
