@neshaboi said:
Btw please specify the exact log files you want, related to networking. I don’t want to post anything with personal info such as user names or what media I have.
The relevant files are the 6 Plex Media Server.log files (oldest being Plex Media Server.5.log)
Would like to see logs with debug logging enabled - no need for verbose logging at this stage starting with fresh logs with a server restart and then ideally covering period when it was working up to time when it is not.
And please do restarts of router / server after switching from uPnP to manually specified port and a port forward.
With regards to uPnP as opposed to manually specified port and a port forward - I have always recommended the manual port forward option - it gives you control over ports used and has been seen many times - even on old plex media server releases to be more reliable than uPnP.
@neshaboi said:
Btw please specify the exact log files you want, related to networking. I don’t want to post anything with personal info such as user names or what media I have.
The relevant files are the 6 Plex Media Server.log files (oldest being Plex Media Server.5.log)
Would like to see logs with debug logging enabled - no need for verbose logging at this stage starting with fresh logs with a server restart and then ideally covering period when it was working up to time when it is not.
And please do restarts of router / server after switching from uPnP to manually specified port and a port forward.
With regards to uPnP as opposed to manually specified port and a port forward - I have always recommended the manual port forward option - it gives you control over ports used and has been seen many times - even on old plex media server releases to be more reliable than uPnP.
Awesome. I totally agree static mapping is best. I’m a networking guy from Slackware days and ran an ISP in the days of dialup. With Cisco networking equipment to our t1. Small now but I loved it I will be sure to get what you need when I get home. I think I have verbose on now so the starting log will have it prob, but I’ll turn it off before I reboot everything and get it on here in a few hours
@neshaboi said:
Also I’m not sure your thoughts about TTL is correct. It’s time to live. Measures in hops or seconds depending on your source. Check out Wikipedia time to live. It looks like you were confusing TTL will the network number (/24 to cover a whole class c network such as 192.168.1.0/24.
Really this looks like it could be resolved by Plex advertising upnp more often. Maybe 30 mins. The network traffic from the machine to the router would be trivial.
Sorry if I missed anything ask again if you wish:)
Nope, not confused about TTL range as described above. As the packet is forwarded, each router hop will decrease the TTL by one so that when the TTL value reaches zero, the packet is discarded and the router will send a request back to the originating host. That’s why value recommendations are given based on subnet, site, region, continent or unrestricted depending on how many hops you intend the record to survive.
@neshaboi, Please don’t take this the wrong way as you seem very eager to help and well intentioned but let’s not have the blind leading the blind. I was asking Plex for official recommendations as to the configuration of UPnP advertisement and TTL settings on the router to better work with the Plex infrastructure. Certainly a UPnP port configuration has to survive a few hops to be accessible outside my home network but there just isn’t enough information out there for me to make an informed decision on what the appropriate value to use is outside spending days testing (time I don’t have). I also don’t have an understanding of how the Plex backend servers (their infrastructure) tells my remote clients how to find the correct port info as I assume must be done on their infrastructure to get it working remotely. Perhaps this is where the problem lives? Where are these servers geographically and how does advertisement and TTL come into play given that scenario?
I can live with a manual port forward. Morbid curiosity makes me want to know how to make UPnP work but I’m not sure it’s possible if even the CTO and Co-Founder gave up…
I did what you asked. Here is the appropriate information for you. I removed my manual port map, rebooted the server and this screenshot shows the port forward UPNP in my router:
As you can see the router at 3:54 had the UPNP mapping to the server (.76) just fine.
At 4:02 you can see plex web shows that the network is fine.
by 4:49 the server no longer believed it had remote access :
At the same time you can see that the mapping for .76 s no longer in my router:
However once I clicked “Retry” the remote access came back.
And viola the port mapping shows back up in the router:
Now I am also attaching the logs before and after. HOWEVER I think this is pretty conclusive that the UPNP is timing out or whatever before plex advertises it again.
Now that I am sick to death of screenshots and log files, I very much hope that this is the end of harping for screenshots or logs related to this issue. I only did it, (as aggravating as it was) to put this part of the discussion to bed.
So now that you have looked at screenshots and hopefully the logs, Please tell us how the problem isn’t exactly as I, and others, have described and related to Plex
Oh and in case it wasn’t obvious from the pics, I upgraded to the new version that apparently came out today, before starting all this just in case it would solve the problem.
@neshaboi said:
Also I’m not sure your thoughts about TTL is correct. It’s time to live. Measures in hops or seconds depending on your source. Check out Wikipedia time to live. It looks like you were confusing TTL will the network number (/24 to cover a whole class c network such as 192.168.1.0/24.
Really this looks like it could be resolved by Plex advertising upnp more often. Maybe 30 mins. The network traffic from the machine to the router would be trivial.
Sorry if I missed anything ask again if you wish:)
Nope, not confused about TTL range as described above. As the packet is forwarded, each router hop will decrease the TTL by one so that when the TTL value reaches zero, the packet is discarded and the router will send a request back to the originating host. That’s why value recommendations are given based on subnet, site, region, continent or unrestricted depending on how many hops you intend the record to survive.
@neshaboi, Please don’t take this the wrong way as you seem very eager to help and well intentioned but let’s not have the blind leading the blind. I was asking Plex for official recommendations as to the configuration of UPnP advertisement and TTL settings on the router to better work with the Plex infrastructure. Certainly a UPnP port configuration has to survive a few hops to be accessible outside my home network but there just isn’t enough information out there for me to make an informed decision on what the appropriate value to use is outside spending days testing (time I don’t have). I also don’t have an understanding of how the Plex backend servers (their infrastructure) tells my remote clients how to find the correct port info as I assume must be done on their infrastructure to get it working remotely. Perhaps this is where the problem lives? Where are these servers geographically and how does advertisement and TTL come into play given that scenario?
I can live with a manual port forward. Morbid curiosity makes me want to know how to make UPnP work but I’m not sure it’s possible if even the CTO and Co-Founder gave up…
Yes but you seemed to be saying that the network number i.e /24 was something else. Sorry if I misunderstood. I Do take a bit of exception to the blind leading the blind thing, I am fluent in networking, I was the network administrator for an ISP for years, and worked technology in the housing department of a major east coast university for a few years. I have multiple unix servers in my home and maintain VPS servers hosting several domains. I didn’t catch at first with plex that the upnp was the problem, as I was refreshing before checking the router so it looked like it was keeping up with it.
That said, there are very few times when you need to adjust the ttl. The advertising doesn’t seem to be the problem here, unless you seem to think your setup is something super special. In my case and it would seem some others, that the server simply isn’t refreshing / checking the upnp often enough, whatever that is. If it’s missing the router advertisement or just timing out. If manual port forwarding fixes it, then it would seem yes upnp is the problem. Yes your client talks to plex servers which tells you where to connect, but if your mapping went down, it can tell your client a port number all day and nothing will happen. The server in your house has to make sure the mapping is refreshed. Not sure where the servers are geographically, but the advertisement comes from your network not their servers. The servers only really tell you where to go, or negotiate a connection through them if direct connection is unavailable. TTL does not come into play here. I have literally never seen a situation where the TTL had anything to do with anything unless there was also a routing problem and the packets were being sent around in circles. There really shouldn’t be any informed decisions about ttl. Really, except in crazy hard to imagine scenarios where a route (through the major providers) is bad, or a server is down, the ttl can safely be left alone.
This link from server fault (a sysadmin site for linux admins)might help explain why never to change the ttl. serverfault
@neshaboi said:
Yes but you seemed to be saying that the network number i.e /24 was something else. Sorry if I misunderstood. I Do take a bit of exception to the blind leading the blind thing, I am fluent in networking… That said, there are very few times when you need to adjust the ttl. The advertising doesn’t seem to be the problem here, unless you seem to think your setup is something super special. In my case and it would seem some others, that the server simply isn’t refreshing / checking the upnp often enough, whatever that is. If it’s missing the router advertisement or just timing out. If manual port forwarding fixes it, then it would seem yes upnp is the problem. Yes your client talks to plex servers which tells you where to connect, but if your mapping went down, it can tell your client a port number all day and nothing will happen. The server in your house has to make sure the mapping is refreshed. Not sure where the servers are geographically, but the advertisement comes from your network not their servers. The servers only really tell you where to go, or negotiate a connection through them if direct connection is unavailable. TTL does not come into play here. I have literally never seen a situation where the TTL had anything to do with anything unless there was also a routing problem and the packets were being sent around in circles. There really shouldn’t be any informed decisions about ttl. Really, except in crazy hard to imagine scenarios where a route (through the major providers) is bad, or a server is down, the ttl can safely be left alone.
I never even mentioned network count though so I’m not sure where you got that idea based on talking about TTL recommendations. Advertisement and TTL absolutely do make a difference as when I messed around with the settings, I saw a difference in how frequently the Plex server lost remote connectivity…
Heck, even Netgear has the following to say about TTL in the user manual:
If you notice that some devices are not being updated or reached correctly, it might be necessary to increase this value.
And Netgear says this about the Advertisement value:
Shorter durations ensure that control points receive current device status at the expense of more network traffic. Longer durations can compromise the freshness of the device status but can significantly reduce network traffic
Adjust the advertisement and TTL on your router and see what effect it has, I bet you see a difference (better or worse).
I’m sorry you feel offended. You may be very fluent in networking but you are using an ISP Verizon router and posting your public IP and open ports publically on the internet? :o Sorry, that was a low jab…I’m trying to be light hearted here. I know my limitations and networking is not an area of expertise for me…
I think your screenshots are very consistent with what I’m experiencing too so I hope Plex can come up with a resolution. Manual port forwarding is easy enough to do but it’s beyond most typical users so UPnP is a seamless solution…if it works.
I’m sorry you feel offended. You may be very fluent in networking but you are using an ISP Verizon router and posting your public IP and open ports publically on the internet? :o Sorry, that was a low jab…I’m trying to be light hearted here. I know my limitations and networking is not an area of expertise for me…
I think your screenshots are very consistent with what I’m experiencing too so I hope Plex can come up with a resolution. Manual port forwarding is easy enough to do but it’s beyond most typical users so UPnP is a seamless solution…if it works.
Eh you didn’t offend me just took exception:). I usually scrub ip’s when I do something like that, but I’m not really worried. I plan to change my ip after all this. but you are definitely right to point that out. . Also not worried about open public ports, just change those as well when this is over. Definitely less work than scrubbing the ip from everything As for using FIOS…It’s either that or Comcast where I live, and I hate fios slightly less lol. Tho they both suck lol. I kinda got that networking isn’t your “thing” no offense, that’s why I was trying to steer you away from playing with things like TTL. It’s best not to change settings unless you are truly confident in what they do. Advertisement and TTL are not related in any way. I read what you said netgear said, but i maintain still that you shouldn’t change them. What they said about advertisement is correct, but their bit about network traffic is a little misleading. Yes there would obviously be more traffic, but how much, realistically? If you have a home network and only a few devices, how much extra traffic could there be? IN a large setup with many network segments, then sure that extra traffic might be noticeable, but I really doubt it. It’s not a large amount of data being sent.
I am stuck using the fios router at this time because it also functions as a mocha bridge to get my tv boxes online for on demand and guide (i think). This router, and I think many isp provided POS routes are somewhat crippled and don’t hae all the options that say the netgear has, because they don’t want people to change things like ttl without knowing and screw something up. Nethear and linksys offer may options, but again most of them should not be changed unless you are confident in what you are doing.
UPNP should work automatically regardless of the routers advertisement time. Let me give you an example. You want to play an xbox game online, but your router advertised 5 minutes ago and isn’t due again for a while. Well then are you just screwed with the xbox port mapping? No, it checks the network and does what it needs to do without the router offering itself…ya know? That’s what I’m saying the plex software should be doing. I
i’m sure it’s complicated by needing to update the plex servers with your information, and that may be why they did it that way, to reduce the traffic to their servers during the refresh.
As far as hops and distance via the network to plex geographical distance is less important than network distance., check this out:
traceroute to www.plex.tv (104.16.138.132), 30 hops max, 60 byte packets
1 10.39.10.1 (10.39.10.1) 398.652 ms 398.655 ms 398.655 ms
2 172.98.67.1 (172.98.67.1) 398.787 ms 398.791 ms 398.793 ms
3 78.152.53.241 (78.152.53.241) 398.625 ms 398.644 ms 398.644 ms
4 ae1-100.cr0-tor1.ip4.gtt.net (173.205.56.217) 398.617 ms 398.597 ms 498.827 ms
5 ip4.gtt.net (173.205.49.186) 498.829 ms 498.829 ms 498.831 ms
6 104.16.138.132 (104.16.138.132) 498.779 ms 399.905 ms 399.890 ms
As you can see I am 6 network hops from the plex servers, though that is through my vpn, so maybe that’s from my vpn in canada. See why I don’t care about an ip getting out? You can check it out yourself from your part of the world. You use windows right? Open a command prompt maybe crtl-r then cmd ad should get a prompt. Then tracert www.plex.tv
I hope our discussion is somewhat helpful or at least interesting
@neshaboi , yes an interesting discussion indeed. I think you’re taking it the right way anyway. Thanks for the extra info. VPNs are fun for sure. My network is somewhat complicated? I have more clients and devices than I can count on two hands so I do often wonder how this affects things but I digress.
If you’re 6 hops away from the plex servers, the default TTL on the Netgear router (and most routers for that matter) is a TTL of 4 how is that not an issue? Hasn’t the record died by the time it reaches Plex?
Based on what I’ve read on the subject, UPnP is closely tied to DLNA and used to allow devices to find each other (on the same subnet) so I think the default settings on Routers are tailored for this same subnet use case and not the “zero configuration” use case for UPnP and remote devices.
Maybe if I can find time when I’m home I’ll set the advertisement to 1 minute and the TTL to 255 and see what havoc I can create.
Also, one other note, I seemed to have less issues when I had IPv6 enabled on my router and Plex but speaking of VPN, it was leaking DNS via IPV6 so IPV6 had to go. :neutral:
@WRXFanatic said: @neshaboi , yes an interesting discussion indeed. I think you’re taking it the right way anyway. Thanks for the extra info. VPNs are fun for sure. My network is somewhat complicated? I have more clients and devices than I can count on two hands so I do often wonder how this affects things but I digress.
If you’re 6 hops away from the plex servers, the default TTL on the Netgear router (and most routers for that matter) is a TTL of 4 how is that not an issue? Hasn’t the record died by the time it reaches Plex?
Based on what I’ve read on the subject, UPnP is closely tied to DLNA and used to allow devices to find each other (on the same subnet) so I think the default settings on Routers are tailored for this same subnet use case and not the “zero configuration” use case for UPnP and remote devices.
Maybe if I can find time when I’m home I’ll set the advertisement to 1 minute and the TTL to 255 and see what havoc I can create.
Also, one other note, I seemed to have less issues when I had IPv6 enabled on my router and Plex but speaking of VPN, it was leaking DNS via IPV6 so IPV6 had to go. :neutral:
Hey again:) . Not sure where you got the ttl of 4 from…Maybe somethine for purely internal use. From another website I get this “TCP and UDP initial TTL values should be set to a “safe” value of at least 60 today.” That website is here
It also states that the new default TTL for windows is 128.
Interestingly my hops with the vpn are less than without. I take 9 w/o the vpn. Interetsing. UPNP and DLNA are related, but different, both trying to make a zero configuratio scenario - not to be confused with zeroconf which is it’s own beast. UPNP is for your internet gateway and network activities. DLNA is really for in house use . So all . your media devices can find one another. All consumer routers come pretty much ready to go with upnp . It’s Just easier for the average consumer who don’t know networking, doesn’t want to know networking and want it to “Just Work”. Let me know how the experiment with TTL and advertisement go
Yeah there is a known issue with IP6 and VPN. They definitely leak and many vpn providers are recommending that you don’t even try and just use IP4. Some VPN’s simply don’t support it so you have no choice. They providers were being blamed for this for a while until they worked out that it was a deficiency inherent in v6. Easy solution only use 4 lol
@neshaboi , the UPnP Advertisement TTL value of 4 I’ve referenced several times is the default value set in the config of Netgear and many other routers for UPnP. Straight from the user manual (the full text of what I snipped above):
The time to live for the advertisement is measured in hops (steps) for each UPnP packet sent. Hops are the steps a packet takes between routers. The number of hops can range from 1 to 255. The default value for the advertisement time to live is 4 hops, which should be fine for most home networks. If you notice that some devices are not being updated or reached correctly, it might be necessary to increase this value.
I’m guessing you can’t adjust your UPnP Advertisement Period or TTL on your FiOS Router? Anyway, that’s why I was referencing the TTL range specifications above and how they generally relate to geography as the TTL value is increased from 1-255 (subnet, site, region, continent or unrestricted). There is no reason to set the UPnP TTL too high but even using a setting of 50 didn’t really improve the situation for me when I tried. The drops were maybe more consistently spaced and I saw more stale UPnP records in the port table on my Router but unlike your example, Plex settings would often show a port of zero until I would click “Retry” which would also fix it with a new UPnP port configuration record in my Router which would match the port listed in the PMS setting.
I mean try to find any legitimate information on UPnP Advertisement Period and TTL on the web. It doesn’t really exist except for Netgear’s various user manual links which are a very generic explanation of the setting. Sure you can find basic info on the general concept of TTL but not directly related to UPnP. It’s kind of amazing how little info there is out there that easily accessible.
Here are the GUI settings on the Netgear so you can see what Advertisement and TTL I’m specifically referencing:
@neshaboi , the UPnP Advertisement TTL value of 4 I’ve referenced several times is the default value set in the config of Netgear and many other routers for UPnP. Straight from the user manual (the full text of what I snipped above):
The time to live for the advertisement is measured in hops (steps) for each UPnP packet sent. Hops are the steps a packet takes between routers. The number of hops can range from 1 to 255. The default value for the advertisement time to live is 4 hops, which should be fine for most home networks. If you notice that some devices are not being updated or reached correctly, it might be necessary to increase this value.
I’m guessing you can’t adjust your UPnP Advertisement Period or TTL on your FiOS Router? Anyway, that’s why I was referencing the TTL range specifications above and how they generally relate to geography as the TTL value is increased from 1-255 (subnet, site, region, continent or unrestricted). There is no reason to set the UPnP TTL too high but even using a setting of 50 didn’t really improve the situation for me when I tried. The drops were maybe more consistently spaced and I saw more stale UPnP records in the port table on my Router but unlike your example, Plex settings would often show a port of zero until I would click “Retry” which would also fix it with a new UPnP port configuration record in my Router which would match the port listed in the PMS setting.
I mean try to find any legitimate information on UPnP Advertisement Period and TTL on the web. It doesn’t really exist except for Netgear’s various user manual links which are a very generic explanation of the setting. Sure you can find basic info on the general concept of TTL but not directly related to UPnP. It’s kind of amazing how little info there is out there that easily accessible.
Here are the GUI settings on the Netgear so you can see what Advertisement and TTL I’m specifically referencing:
Heya again
Ok so I think I see what that means. The TTL for the UPNP in that case seems to be entirely for the packets inside your network. I know you said your network is complex, but I doubt more than 4 hops. A hop would be another router perhaps or something like that. Internal home networks rarely have additional routers in the mix inside, but it is not unheard of I suppose. That seems to be . the ttl that it's talking about. You would most likely never need more than that, let alone 50 for the internal network. I thought you were talking about the actual network traffic leaving your router. Lookig at that screenshot it's obvious now. Anything more would really just be putting a hat on a hat, as they say. I really don't think that either of those setting have anything to do with anything in regards to this.
As I said the advertising really shouldn’t matter either. Regardless of the advertisement time, plex, or xbox or playstation or your torrent program will all request port mapping independent of the advertise, or your game/media/torrent wouldn’t get a port until advertised. These programs ask for it immediately and get a port regardless. I don’t think you tweaking anything on that page will help with plex, and it’s kinda crazy they give the option to change them. How many routers and gateways do they really think you’ll have in your house? Or maybe it’s thinking it might be for a small business or something like that. Perhaps in a college dorm setting you might have your own router and have to make hops to the schools devices, but that would probablly end in double nat and that’s a whole other problem outside the scope here.
It really just looks like the solution is static port mapping and hope plex solves it. It can’t just be us with problems. This exact situation is why static is so much better
And to come back around to plex, I wonder where @sa2000 has gone off to, after all that screenshot and log business. Perhaps his shift ended, Maybe tomorrow
@neshaboi said:
Report that it changed after version 0.9blahbah. again that all points to your software. Starting any search elsewhere, with these reports, seems like classic hey look over they tactics. Perhaps were a little harsh but all we get, even from you, is basically how it couldn’t be your stuff, despite points that way. That frankly pisses people off.
(To be clear, in my post I blamed our stuff as well at first, which is why I dug into it.)
Also, one regression we have identified is that there may be cases in which the indicator light shows up RED when you actually do have remote access. We’re looking into it.
But OK if means so much to you when I get home I’ll undo my manual mapping breaking it for me, wait an hour or so and then send you log when it’s offline again.
If you’re getting consistent behavior with manual port mapping, by all means stay there; as I indicated, there’s no real advantage to the automatic port mapping besides not having to know how to do a manual port mapping
I did what you asked. Here is the appropriate information for you. I removed my manual port map, rebooted the server and this screenshot shows the port forward UPNP in my router:
As you can see the router at 3:54 had the UPNP mapping to the server (.76) just fine.
At 4:02 you can see plex web shows that the network is fine.
by 4:49 the server no longer believed it had remote access :
At the same time you can see that the mapping for .76 s no longer in my router:
However once I clicked “Retry” the remote access came back.
And viola the port mapping shows back up in the router:
Now I am also attaching the logs before and after. HOWEVER I think this is pretty conclusive that the UPNP is timing out or whatever before plex advertises it again.
Now that I am sick to death of screenshots and log files, I very much hope that this is the end of harping for screenshots or logs related to this issue. I only did it, (as aggravating as it was) to put this part of the discussion to bed.
So now that you have looked at screenshots and hopefully the logs, Please tell us how the problem isn’t exactly as I, and others, have described and related to Plex
Oh and in case it wasn’t obvious from the pics, I upgraded to the new version that apparently came out today, before starting all this just in case it would solve the problem.
Thanks for all the logs and screenshots. Been going through them. In the last log I can see that connectivity was ok at 20:01:37
Mar 29, 2017 20:01:37.481 [0x7ff5f13f8700] DEBUG - Request: [54.171.49.114:4998 (WAN)] GET /identity (7 live) TLS Signed-in Token (neshaboi)
Mar 29, 2017 20:01:37.481 [0x7ff5f13f8700] VERBOSE - * Host => 74-98-xxx-xxx.d988d0aa4913432bb1f66a5601340062.plex.direct:28944
Mar 29, 2017 20:01:37.482 [0x7ff603fff700] DEBUG - Completed: [54.171.49.114:4998] 200 GET /identity (7 live) TLS 0ms 356 bytes
Mar 29, 2017 20:01:37.798 [0x7ff600fff700] DEBUG - EventSource: Got event [data] '<Message address="74.98.xxx.xxx" port="28944" asyncIdentifier="d730b7ab-156c-4acf-98fe-56f82ed602b3" connectivity="1" command="notifyConnectivity"/>'
Mar 29, 2017 20:01:37.798 [0x7ff600fff700] DEBUG - PubSub: Got notified of reachability: 1 for 74.98.xxx.xxx:28944
but at 20:40:13 it was no longer
Mar 29, 2017 20:40:13.129 [0x7ff600fff700] DEBUG - EventSource: Got event [data] '<Message address="74.98.xxx.xxx" port="28944" asyncIdentifier="0239f492-0bc4-46ae-afeb-a03ea1ff9dd4" connectivity="0" command="notifyConnectivity"/>'
Mar 29, 2017 20:40:13.129 [0x7ff600fff700] DEBUG - PubSub: Got notified of reachability: 0 for 74.98.xxx.xxx:28944
There was nothing the Plex Media Server was doing between 20:01:37 and 20:40:13 that may have affected this. And it does point to the route to the server not in place.
My advice is always to switch to a port forward and use the manually specify port option. I have always recommended
And to come back around to plex, I wonder where @sa2000 has gone off to, after all that screenshot and log business. Perhaps his shift ended, Maybe tomorrow
It is past bed time - but I was close to concluding my investigation into the logs and screenshots.
I did what you asked. Here is the appropriate information for you. I removed my manual port map, rebooted the server and this screenshot shows the port forward UPNP in my router:
As you can see the router at 3:54 had the UPNP mapping to the server (.76) just fine.
At 4:02 you can see plex web shows that the network is fine.
by 4:49 the server no longer believed it had remote access :
At the same time you can see that the mapping for .76 s no longer in my router:
However once I clicked “Retry” the remote access came back.
And viola the port mapping shows back up in the router:
Now I am also attaching the logs before and after. HOWEVER I think this is pretty conclusive that the UPNP is timing out or whatever before plex advertises it again.
Now that I am sick to death of screenshots and log files, I very much hope that this is the end of harping for screenshots or logs related to this issue. I only did it, (as aggravating as it was) to put this part of the discussion to bed.
So now that you have looked at screenshots and hopefully the logs, Please tell us how the problem isn’t exactly as I, and others, have described and related to Plex
Oh and in case it wasn’t obvious from the pics, I upgraded to the new version that apparently came out today, before starting all this just in case it would solve the problem.
The failure I highlighted earlier was for a different time from the times for the screenshots.
Regarding the loss of remote access at 4:49 pm, a remote connection was active at 3:57:47 pm. At 3:58:07 pm the connection dropped and after that there were UDP issues logged to do with discovery / SSDP - lasted between 3:58 pm and 4:50pm.
Mar 29, 2017 15:58:07.145 [0x7f832dbfe700] VERBOSE - We didn't receive any data from 208.54.90.199:47856 in time, dropping connection.
Mar 29, 2017 15:58:07.463 [0x7f832e3ff700] VERBOSE - We didn't receive any data from 208.54.90.199:31795 in time, dropping connection.
Mar 29, 2017 15:58:07.463 [0x7f832dbfe700] VERBOSE - We didn't receive any data from 208.54.90.199:44260 in time, dropping connection.
Mar 29, 2017 15:58:07.888 [0x7f832dbfe700] VERBOSE - We didn't receive any data from 208.54.90.199:52338 in time, dropping connection.
Mar 29, 2017 16:07:10.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798816 seconds: 192.168.1.76
Mar 29, 2017 16:07:12.189 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:21:30.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798806 seconds: 192.168.1.76
Mar 29, 2017 16:21:30.187 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:23:40.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 29.797316 seconds: 192.168.1.76
Mar 29, 2017 16:23:41.188 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:25:40.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798810 seconds: 192.168.1.76
Mar 29, 2017 16:25:41.188 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:33:50.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.798144 seconds: 192.168.1.76
Mar 29, 2017 16:33:50.187 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:44:00.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798879 seconds: 192.168.1.76
Mar 29, 2017 16:44:02.189 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:50:10.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.912304 seconds: 192.168.1.10
Mar 29, 2017 16:50:10.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.798129 seconds: 192.168.1.76
Mar 29, 2017 16:50:10.188 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:50:28.331 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.10 (https://192.168.1.10:8888)
Whatever it was, it affected the tcp connection for the remote connection from 208.54.90.199 as well as the udp traffic for SSDP / Discovery
I wonder if the router log would have some relevant information
For the later failure at 20:40:13 (my earlier post), there was also log entries to do with SSDP UDP packets -
Mar 29, 2017 20:05:05.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 27.795893 seconds: 192.168.1.76
Mar 29, 2017 20:05:07.809 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 20:11:05.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798790 seconds: 192.168.1.76
Mar 29, 2017 20:11:15.808 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 20:21:25.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798678 seconds: 192.168.1.76
Mar 29, 2017 20:21:27.810 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 20:27:35.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798645 seconds: 192.168.1.76
Mar 29, 2017 20:27:37.810 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 20:37:45.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.797921 seconds: 192.168.1.76
Mar 29, 2017 20:37:54.807 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Not sure of the relevance of this.
My recommendation is to try to run with a port forward and manually specified port and see how that compares.
The failure I highlighted earlier was for a different time from the times for the screenshots.
Regarding the loss of remote access at 4:49 pm, a remote connection was active at 3:57:47 pm. At 3:58:07 pm the connection dropped and after that there were UDP issues logged to do with discovery / SSDP - lasted between 3:58 pm and 4:50pm.
Mar 29, 2017 15:58:07.145 [0x7f832dbfe700] VERBOSE - We didn't receive any data from 208.54.90.199:47856 in time, dropping connection.
Mar 29, 2017 15:58:07.463 [0x7f832e3ff700] VERBOSE - We didn't receive any data from 208.54.90.199:31795 in time, dropping connection.
Mar 29, 2017 15:58:07.463 [0x7f832dbfe700] VERBOSE - We didn't receive any data from 208.54.90.199:44260 in time, dropping connection.
Mar 29, 2017 15:58:07.888 [0x7f832dbfe700] VERBOSE - We didn't receive any data from 208.54.90.199:52338 in time, dropping connection.
Mar 29, 2017 16:07:10.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798816 seconds: 192.168.1.76
Mar 29, 2017 16:07:12.189 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:21:30.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798806 seconds: 192.168.1.76
Mar 29, 2017 16:21:30.187 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:23:40.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 29.797316 seconds: 192.168.1.76
Mar 29, 2017 16:23:41.188 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:25:40.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798810 seconds: 192.168.1.76
Mar 29, 2017 16:25:41.188 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:33:50.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.798144 seconds: 192.168.1.76
Mar 29, 2017 16:33:50.187 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:44:00.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798879 seconds: 192.168.1.76
Mar 29, 2017 16:44:02.189 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:50:10.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.912304 seconds: 192.168.1.10
Mar 29, 2017 16:50:10.185 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.798129 seconds: 192.168.1.76
Mar 29, 2017 16:50:10.188 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 16:50:28.331 [0x7f8325fff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.10 (https://192.168.1.10:8888)
Whatever it was, it affected the tcp connection for the remote connection from 208.54.90.199 as well as the udp traffic for SSDP / Discovery
I wonder if the router log would have some relevant information
For the later failure at 20:40:13 (my earlier post), there was also log entries to do with SSDP UDP packets -
Mar 29, 2017 20:05:05.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 27.795893 seconds: 192.168.1.76
Mar 29, 2017 20:05:07.809 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 20:11:05.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798790 seconds: 192.168.1.76
Mar 29, 2017 20:11:15.808 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 20:21:25.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798678 seconds: 192.168.1.76
Mar 29, 2017 20:21:27.810 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 20:27:35.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.798645 seconds: 192.168.1.76
Mar 29, 2017 20:27:37.810 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Mar 29, 2017 20:37:45.806 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.797921 seconds: 192.168.1.76
Mar 29, 2017 20:37:54.807 [0x7ff5fa3ff700] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.1.76 (http://192.168.1.76:32469/DeviceDescription.xml)
Not sure of the relevance of this.
My recommendation is to try to run with a port forward and manually specified port and see how that compares.
I am not sure what you mean that the failure highlighted earlier is different from the screenshots. I don’t know what you’re implying. Those screenshots and the included logs are from the times shown in the screenshot, I didn’t take them at one time and then sneakily give you logs from a different time. Perhaps it’s due to the server reporting time in UTC rather than EST.
You’re not sure the relevance of this? Those are the logs and screenshots YOU asked for. I don’t like what appears to be happening there. Almost like you’re trying to invalidate my info cause you don’t like it.
You recommend manual forwarding? Really? You mean after we discussed it at length earlier regarding port forwarding and UPNP, almost ad nauseam, you recommend that? Whew thanks that was a big help. Couldn’t have concluded that without those logs.
Do you see why I was annoyed at even having to give the logs? I was just sure something like that would be the answer.
As was stated NUMEROUS TIMES - there is a upnp problem. You recognize that by telling us static port mapping WHICH IS NOT A SOLUTION FOR MANY USERS. Those w/o certain technical skills wouldn’t be able to do it.
This is very disappointing. I really didn’t expect you to throw parts of the log at us showing some problem with upnp. It is also ridiculous! I have a problem with upnp. Two other people on here have problems with upnp. YOU GUYS - in your wisdom tell me it’s a problem and port forward. I was really hoping that you guys might acknowledge a problem that you need to work on. Making routers with perhaps buggy upnp implementation work really is what YOU need to do
What I wanted was an acknowledgement from plex. Yes there’s a problem, yes we’re working on it. NOTHING like that, just a kick the can…somehow blaming the time in my logs, anything OTHER than there is a problem, you’re going to try and fix it for others, just a blow off, go static, and what I assume is you ignoring it any further.
@neshaboi said:
Perhaps it’s due to the server reporting time in UTC rather than EST.
I must have missed your note about the server being 4 hours ahead of the times you mentioned and show on the screenshot.
So the failure i found first at server time 20:40:13 (your time 4:40:13 pm) was the right one and that ties in with you discovering at 4:49pm that remote access was down and the uPnP route in the router for 28944 was no longer there.
I will discuss with the development team but there was no mapping related activity by Plex Media Server between the time when it was working at server time 20:01:37 (observed at your time 4:02pm) and when it dropped out at server time 20:40:13 (your observed time 4:49 pm). If the uPnP port mapping is removed by Plex Media Server then there would be some logging to indicate that.
Issues with uPnP are not new. There has always been problems and reliability issues and recommendations to switch to static port forward have been made many times on the forums over the past years.
By asking for the logs I wanted to see if there was any Plex Media Server actions that may have led to the loss of connections but the logs do not show any such action.
I have been looking into how uPnP port mapping is being done. So I switched my server to automatic uPnP port mapping and I have run wireshark to capture all communications with the router.
The port mapping is very straightforward. We use a lease period of 0 which means unlimited but we do repeat the request hourly.
The mapping has Plex Media Server corresponding log entry, e.g. in your case
Mar 29, 2017 19:58:16.803 [0x7ff602de2700] DEBUG - NAT: UPnP, mapped port 28944 to 192.168.1.76:32400.
This was at 3:58:16 pm
It went wrong in your router before the hour - so Plex Media Server would not have been doing any action on the router when it went wrong
You could run wireshark (or equivalent) filtering on the IP of the router and protocol http
Well just an update. After numerous troubleshooting I finally downgraded it and it’s been working without a problem all day. I’m thinking it was something with the recent update.
@mthomas184 said:
Well just an update. After numerous troubleshooting I finally downgraded it and it’s been working without a problem all day. I’m thinking it was something with the recent update.
What are the 2 versions? I could run wireshark with the 2 versions and compare how we interact with the router.
My earlier tests using version 1.5.2 did not show any problem and the mapping was sent to the router every hour and the lease was set to zero. The router acknowledged each case with a response indicating connected ok
And what is the model of the FIOS router?
Firmware version?
For what it’s worth, I’ve been having the same problem since I updated to the newest Plex server version. Never been an issue before, now it’s a pain in the behind.
I will be sure to get what you need when I get home. I think I have verbose on now so the starting log will have it prob, but I’ll turn it off before I reboot everything and get it on here in a few hours
As for using FIOS…It’s either that or Comcast where I live, and I hate fios slightly less lol. Tho they both suck lol. I kinda got that networking isn’t your “thing” no offense, that’s why I was trying to steer you away from playing with things like TTL. It’s best not to change settings unless you are truly confident in what they do. Advertisement and TTL are not related in any way. I read what you said netgear said, but i maintain still that you shouldn’t change them. What they said about advertisement is correct, but their bit about network traffic is a little misleading. Yes there would obviously be more traffic, but how much, realistically? If you have a home network and only a few devices, how much extra traffic could there be? IN a large setup with many network segments, then sure that extra traffic might be noticeable, but I really doubt it. It’s not a large amount of data being sent.
Thanks for the extra info. VPNs are fun for sure. My network is somewhat complicated? I have more clients and devices than I can count on two hands so I do often wonder how this affects things but I digress.
