I have just tested with netcat from my PC to VM and it seems to receive UDP data fine
I am convinced this is a networking issue but cannot yet identify the issue.
I am uncertain if it is in the VLAN / network config of the switch or elsewhere.
General practice is to VLAN tag and place that VLAN on a separate subnet.
This is how my guest WiFi is configured. It is VLAN isolated at the switch as well as subnet broadcast boundary. Further, only the pfSense router sees both segments.
If you’ve got MAC VLAN going on, I suggest you move it over to layer 3.
I understand what you’re saying.
What I can’t resolve is:
- We use ESXi , without VLANs, so we can test multiple clients
- if this was a wide scale issue (transcoder failing with 404 - not found) it wouldn’t have made it to beta… we’d have found it.
- I have 3 different LANs running here (main, guest, and lab VPN) without any interference or failure.
The $100 question is what is the difference between my and your switch configuration
Thanks for all your help so far, its greatly appreciated! I’m just going to spend a few mins simplifying the network and removing VLANs to help solve the issue. I will report back soon
Some progress at least, I can now get it to work but only by losing my internet connection, this may be where my weaker networking knowledge lets me down.
Currently my ESXI vSwitch is configured to use VLAN ID 0. My managed switch is now not tagging at all.
My router (Default one from ISP) is using VLAN ID 101 (the default setting), i can access everything fine on my PMS apart from this transcoding issue (more accurately status updates not reaching PMS).
If i change my router VLAN ID setting to 1 i can access everything fine AND transcoding works perfectly, no timeouts killing the process GREAT!! …but, with this VLANID on my router i can no longer get an internet connection, and ISP docs state VLANID must be set to 101.
If i set my ESXI vSwitch VLAN ID to 101 i lose access to all the VMs on that switch.
I know this is above and beyond for plex support, but if anybody can give me some advice i’d be forever grateful
There is your driving VLAN ID. 101
That’s the number you must live by. WHY an ISP is mandating VLAN 101 is beyond any sense of sanity.
Once you switch everything over to VLAN 101, all access will be restored.
However, before doing that, I urge contacting the ISP and finding out why a VLAN ID is required. That’s advanced networking to be putting in people’s homes
Thats seems to be a problem too, if i set the vSwitch VLAN ID to be 101 i can no longer access any VMs on that switch. If i set it to 4095 or 0 i can access the VMs but get the transcoding timeout. Am i missing something?
The ESXI host and my PC are both connected to a now ‘dumb’ switch which is then connected to the router, so nothing fancy.
Any details on the status update UDP data, what port are they on and when received what should i expect to see in the log?
What you will see in the log are “progress” posts during playback. Specifically, they are timeline events.
It still seems that i see these events in the log even when i’m experiencing issues. When the transcoder stops the client then keeps reporting the same progress as expected
Note: This was the output of greping for timeline
Nov 29, 2018 00:13:25.933 [0x7ffbe97fe700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=26575&playQueueItemID=40875&state=playing&hasMDE=1&time=26000&duration=3500000 (15 live) TLS GZIP 3ms 818 bytes (pipelined: 104)
Nov 29, 2018 00:13:35.940 [0x7ffbe67ff700] DEBUG - Request: [192.168.1.3:6488 (Subnet)] GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=36580&playQueueItemID=40875&state=playing&hasMDE=1&time=36000&duration=3500000 (15 live) TLS GZIP Signed-in Token (a123oclock)
Nov 29, 2018 00:13:35.941 [0x7ffbe67ff700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state playing, progress of 36000/3500000ms for guid=, ratingKey=34229 url=, key=/library/metadata/34229, containerKey=, metadataId=34229, source=
Nov 29, 2018 00:13:35.946 [0x7ffbe97fe700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=36580&playQueueItemID=40875&state=playing&hasMDE=1&time=36000&duration=3500000 (15 live) TLS GZIP 6ms 837 bytes (pipelined: 125)
Nov 29, 2018 00:13:45.943 [0x7ffbeafff700] DEBUG - Request: [192.168.1.3:6488 (Subnet)] GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=46588&playQueueItemID=40875&state=playing&hasMDE=1&time=46000&duration=3500000 (13 live) TLS GZIP Signed-in Token (a123oclock)
Nov 29, 2018 00:13:45.944 [0x7ffbeafff700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state playing, progress of 46000/3500000ms for guid=, ratingKey=34229 url=, key=/library/metadata/34229, containerKey=, metadataId=34229, source=
Nov 29, 2018 00:13:45.947 [0x7ffbe9fff700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=46588&playQueueItemID=40875&state=playing&hasMDE=1&time=46000&duration=3500000 (13 live) TLS GZIP 3ms 841 bytes (pipelined: 146)
Nov 29, 2018 00:13:55.955 [0x7ffbe77ff700] DEBUG - Request: [192.168.1.3:6488 (Subnet)] GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=56592&playQueueItemID=40875&state=playing&hasMDE=1&time=56000&duration=3500000 (13 live) TLS GZIP Signed-in Token (a123oclock)
Nov 29, 2018 00:13:55.956 [0x7ffbe77ff700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state playing, progress of 56000/3500000ms for guid=, ratingKey=34229 url=, key=/library/metadata/34229, containerKey=, metadataId=34229, source=
Nov 29, 2018 00:13:55.958 [0x7ffbe97fe700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=56592&playQueueItemID=40875&state=playing&hasMDE=1&time=56000&duration=3500000 (12 live) TLS GZIP 3ms 841 bytes (pipelined: 167)
Nov 29, 2018 01:14:40.895 [0x7ffbe77ff700] DEBUG - Request: [192.168.1.3:6488 (Subnet)] GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=66597&playQueueItemID=40875&state=playing&hasMDE=1&time=66000&duration=3500000 (10 live) TLS GZIP Signed-in Token (a123oclock)
Nov 29, 2018 01:14:40.896 [0x7ffbe77ff700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state playing, progress of 66000/3500000ms for guid=, ratingKey=34229 url=, key=/library/metadata/34229, containerKey=, metadataId=34229, source=
Nov 29, 2018 01:14:40.902 [0x7ffbe97fe700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=66597&playQueueItemID=40875&state=playing&hasMDE=1&time=66000&duration=3500000 (10 live) TLS GZIP 7ms 571 bytes (pipelined: 188)
Nov 29, 2018 01:14:50.923 [0x7ffbe2fff700] DEBUG - Request: [192.168.1.3:6488 (Subnet)] GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=76602&playQueueItemID=40875&state=playing&hasMDE=1&time=117000&duration=3500000 (11 live) TLS GZIP Signed-in Token (a123oclock)
Nov 29, 2018 01:14:50.924 [0x7ffbe2fff700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state playing, progress of 117000/3500000ms for guid=, ratingKey=34229 url=, key=/library/metadata/34229, containerKey=, metadataId=34229, source=
Nov 29, 2018 01:14:50.937 [0x7ffbe9fff700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=76602&playQueueItemID=40875&state=playing&hasMDE=1&time=117000&duration=3500000 (11 live) TLS GZIP 13ms 572 bytes (pipelined: 197)
Nov 29, 2018 01:15:00.927 [0x7ffbc47fb700] DEBUG - Request: [192.168.1.3:6488 (Subnet)] GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=86607&playQueueItemID=40875&state=playing&hasMDE=1&time=127000&duration=3500000 (12 live) TLS GZIP Signed-in Token (a123oclock)
Nov 29, 2018 01:15:00.928 [0x7ffbc47fb700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state playing, progress of 127000/3500000ms for guid=, ratingKey=34229 url=, key=/library/metadata/34229, containerKey=, metadataId=34229, source=
Nov 29, 2018 01:15:00.934 [0x7ffbe9fff700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=86607&playQueueItemID=40875&state=playing&hasMDE=1&time=127000&duration=3500000 (12 live) TLS GZIP 7ms 572 bytes (pipelined: 200)
Nov 29, 2018 01:15:09.131 [0x7ffbc47fb700] DEBUG - Request: [192.168.1.3:6488 (Subnet)] GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=94613&playQueueItemID=40875&state=buffering&hasMDE=1&time=135000&duration=3500000 (10 live) TLS GZIP Signed-in Token (a123oclock)
Nov 29, 2018 01:15:09.133 [0x7ffbc47fb700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state buffering, progress of 135000/3500000ms for guid=, ratingKey=34229 url=, key=/library/metadata/34229, containerKey=, metadataId=34229, source=
Nov 29, 2018 01:15:09.139 [0x7ffbe9fff700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=94613&playQueueItemID=40875&state=buffering&hasMDE=1&time=135000&duration=3500000 (10 live) TLS GZIP 7ms 572 bytes (pipelined: 202)
Nov 29, 2018 01:15:10.770 [0x7ffbc47fb700] DEBUG - Request: [192.168.1.3:6488 (Subnet)] GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=95194&playQueueItemID=40875&state=paused&hasMDE=1&time=135000&duration=3500000 (10 live) TLS GZIP Signed-in Token (a123oclock)
Nov 29, 2018 01:15:10.771 [0x7ffbc47fb700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state paused, progress of 135000/3500000ms for guid=, ratingKey=34229 url=, key=/library/metadata/34229, containerKey=, metadataId=34229, source=
Nov 29, 2018 01:15:10.782 [0x7ffbe9fff700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=95194&playQueueItemID=40875&state=paused&hasMDE=1&time=135000&duration=3500000 (10 live) TLS GZIP 11ms 572 bytes (pipelined: 203)
Nov 29, 2018 01:15:10.931 [0x7ffbc47fb700] DEBUG - Request: [192.168.1.3:6488 (Subnet)] GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=95194&playQueueItemID=40875&state=paused&hasMDE=1&time=135000&duration=3500000 (10 live) TLS GZIP Signed-in Token (a123oclock)
Nov 29, 2018 01:15:10.932 [0x7ffbc47fb700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state paused, progress of 135000/3500000ms for guid=, ratingKey=34229 url=, key=/library/metadata/34229, containerKey=, metadataId=34229, source=
Nov 29, 2018 01:15:10.937 [0x7ffbe9fff700] DEBUG - Completed: [192.168.1.3:6488] 200 GET /:/timeline?ratingKey=34229&key=%2Flibrary%2Fmetadata%2F34229&playbackTime=95194&playQueueItemID=40875&state=paused&hasMDE=1&time=135000&duration=3500000 (10 live) TLS GZIP 6ms 572 bytes (pipelined: 204)
Are you UDP packets always going to the same port? I might do a packet capture and see if i can figure out what is going wrong
port numbers outbound always change, inbound UDP is always to the established ports (PMS is listening there).
- TCP: 32400 (for access to the Plex Media Server) [required]
The following ports are also used for different services:
- UDP: 1900 (for access to the Plex DLNA Server)
- TCP: 3005 (for controlling Plex Home Theater via Plex Companion)
- UDP: 5353 (for older Bonjour/Avahi network discovery)
- TCP: 8324 (for controlling Plex for Roku via Plex Companion)
- UDP: 32410, 32412, 32413, 32414 (for current GDM network discovery)
- TCP: 32469 (for access to the Plex DLNA Server)
The most important ports are those in the 32400 - 32414 range
In your earlier post, I missed an important point.
Notice:
Nov 29, 2018 01:15:10.932 [0x7ffbc47fb700] DEBUG - Client [wqxc0hb8hz5nch9h5ql0egto] reporting timeline state paused,
Paused playback. It is not reporting active playback.
It only reports paused after the transcoder is killed for being idle
Let me go back through again with a fresh set of eyes in the morning. Something isn’t right with what’s happening for you.
I will also ask for extra eyes
Yeah i think i need to do the same. Attached full logs from earlier. The weirdest thing is i can make it work by changing the VLAN on the router, but then lose access to internet. But that should change for both PC and ESXI as theyre plugged into the same switch attached to a single port of the router.
I was thinking maybe the vlan change on the router was a red herring and it was the lack of internet that caused it to work, as if it was a DNS rebinding issue. But keeping the router VLAN at 101 and disconnecting WAN doesnt fix the issue.
Also do i need those UDP ports to be forwarded for remote streams? How do they send their status to PMS?
I don’t know what isp or connection you have, but I have never heard of a vlan being required for the end user side of the internet.
That said, I would suggest that if a vlan is required by your isp, it is (or should be) only necessary at the WAN link.
Your LAN side (192.168.1.x) should not need any ISP vlan, because the router should be routing to/from the lan/wan and using NAT to reach anything outside the local subnet.
My ISP is EE (UK) and the router is a brightbox 2
Here is a screenshot of the admin interface, its not clear what the VLAN is for, whether is for the LAN or WAN. If i change from 101 i lose internet. If i change to 1 the transcode doesnt timeout?? I’m so confused
Ok that does make a little sense.
It appears what you have is a bridged PPPOE connection with the ISP doing carrier grade NAT and possibly dhcp for your whole internal network?
Basically, your router is not routing.
It is bridging.
I would suggest you contact your ISP and ask for a non-bridged router/connection with a public ip.
Alternatively you could buy a separate router of your own choice and essentially go through a double NAT situation.
All of which is sort of beyond the scope of the plex forums.
to help visualize, this is what a normal internet connection looks like;
isp side - public ip x.x.x.x WAN | LAN private ip 192.168.1.1 internal network side
where the router has 2 ips, the public ip, and the private ip and essentially converts and shares your public ip for internet traffic, to the lan private ips.
however in your case, the ‘router’ is actually in bridge mode using PPPOE and does not have a public ip.
Your bridge is like using a dumb switch between your ISP and your LAN, there is no conversion between the public ip and your private lan ips happening (that appears to be happening on the ISP side hardware).
