Als Plex via het ene netwerkpad werkt maar via het andere niet, laat je de serverconfiguratie ongewijzigd en test je het pad dat verandert.
Wifi-, Ethernet- en VPN-interfaces kunnen verschillende IP-adressen, DNS-servers, routes, MTU's, VLAN's en firewallbeleidsregels gebruiken, zelfs op dezelfde client. Een wijziging voor de hele server is niet de juiste eerste stap wanneer dezelfde media en hetzelfde account via het ene pad wel werken. Vergelijk directe bereikbaarheid van de server, DNS-resolutie, routeselectie en afspeelmodus op elke interface.
Vergelijk adres en route voordat je Plex-instellingen aanpast
De interface die problemen geeft, kan een ander subnet bereiken of een andere standaardroute kiezen. Controleer het server-IP-adres en de route vanaf de client in plaats van op het netwerklabel te vertrouwen.
Wanneer Ethernet en wifi beide actief zijn, kunnen route-metrics ervoor zorgen dat de interfaces verschillende paden naar dezelfde bestemming kiezen. Richt de eerste diagnose daarom op routing en interfacebeleid, niet op Plex-instellingen.
Ping of verbind met het serveradres via beide paden, vergelijk het IP-adres en subnet van de client en controleer de route die voor poort 32400 wordt gebruikt. Als Ethernet de server niet rechtstreeks kan bereiken, houd de oplossing dan op netwerkniveau.
Controleer DNS en VPN-routing afzonderlijk
Een VPN kan zowel de routeprioriteit als DNS wijzigen zonder de Plex-toepassing aan te passen. Split-tunneling kan er ook voor zorgen dat antwoorden via een andere interface worden verzonden dan de interface waarop het verzoek binnenkwam.
Split-tunneling kan mislukken wanneer antwoordverkeer via de VPN-route vertrekt in plaats van via de interface waarop het verzoek binnenkwam. Daardoor wordt een verder geldig Plex-pad verbroken.
Schakel de VPN alleen lang genoeg uit om een controletest uit te voeren, schakel hem daarna weer in en vergelijk de routetabellen. Los asymmetrische routing of het split-tunnelbeleid op voordat je media- of database-instellingen aanpast.
Test de MTU wanneer kleine verzoeken werken maar streams vastlopen
Een pad kan kleine besturingsgegevens doorlaten terwijl grotere pakketten fragmenteren of een time-out krijgen. Dit patroon is vooral relevant bij VPN-tunnels en bepaalde mobiele verbindingen of ISP-links.
Gedeeltelijke connectiviteit kan leiden tot MTU-gevoelige Plex-problemen via het ene transport terwijl een ander pad wel werkt. Daardoor is pakketgrootte een gerichte test voor VPN- of ISP-specifieke haperingen.
Gebruik een pad-MTU-test of verlaag de tunnel-MTU tijdelijk en gecontroleerd. Als het afspelen stabiel wordt zonder een wijziging in Plex, houd de diagnose dan op transportniveau.
Test Plex pas opnieuw nadat de basisconnectiviteit stabiel is
Wanneer directe bereikbaarheid, routing, DNS en MTU consistent zijn, test je hetzelfde Plex-item en dezelfde kwaliteit via elk pad. Zo voorkom je dat een netwerkoplossing wordt verward met een wijziging in clienttranscodering.
Controleer voordat je teruggaat naar de Plex-instellingen of netwerkfouten en verzadiging ontbreken op het herstelde pad. Speel daarna hetzelfde item met dezelfde kwaliteit opnieuw af terwijl de netwerkvariabele stabiel blijft.
Als het netwerkpad stabiel is maar één client nog steeds faalt, ga dan verder met compatibiliteit van de client of de opgeslagen status. Houd een bekende Plex-streamingroute op afstand als controle aan in plaats van de netwerkinstellingen voor de hele server opnieuw te openen.
Ondersteuning & Tips
Meer om te lezen

Moet je een live back-up van Jellyfin maken of de service eerst stoppen?
Geef de voorkeur aan back-ups van gestopte services voor eenvoud; gebruik live snapshots alleen wanneer de applicatiestatus consistent wordt vastgelegd en herstelprocedures zijn getest.

Waarom draait Jellyfin zo warm of luidruchtig als niemand streamt?
Hittesterkte tijdens inactiviteit wijst meestal op achtergrondwerk of een belasting door gedeelde hosting. Identificeer daarom het actieve proces en de geplande taak voordat je...

Wanneer moet je Jellyfin opnieuw opbouwen in plaats van repareren?
Kies voor opnieuw opbouwen in plaats van repareren wanneer runtime-drift het probleem is en de persistente status is geback-upt; verwijder de enige goede database...

