PMS Direct Play Networking (SOLVED)

Plex Media Server NAS & Devices
1

Server Version#: 1.20.3.3437 (Synology DS1812+)
Player Version#: 6.6.12.6662-64d4a08ac-Plex (TCL Roku TV R613)

PMS cannot maintain high bit-rate Direct Play stream from Synology DS1812+.
Im playing high(est) bitrate 4k mkvs (1917, some MCU films, etc) and playback fails with error that network is insufficient for the quality/bitrate.

I suspected issues everywhere but PMS. So I began redundantly doing isolation testing everything else. I thought it was bad wifi to the tv, insufficient bandwidth on the 10/100 nic on the tv hardwired, the processor on the tv not being able to keep up, my wifi roiuter/AP not being able to keep up etc.

I cam to this conclusion by spinning up a second instance of PMS on my wifes computer, compying 1917 onto it, then playing it direct direct play across the same network connections to the same client. It didnt buffer drop/buffer once.

That only leaves 2 things that could be broken, my Synology itself, or PMS.
Using SMB to copy 1917 off the NAS to my wifes computer it saturated the NAS’s gigabit nic with stable and sustained transfer speeds ~108-130MBps which is 10x the needed speed to Direct Play the movie which seems to rule out network or drive access hardware issues.

1917 is listed in PLEX at `85Mbps, but I know it routinely can spike to 120-150 Mbps which outstrips the capability of the TVs ethernet port, but the AC wireless on the tv was able to handle it fully when played from my wifes desktop PMS install.

I cant be sure if its a bug in PMS for synology or some rotten configuration causing the issue. I explicity disabled transcoding on each server, and select original quality force direct play on the client. While streaming from synology, not a single resource is stressed (disk io, proc, ram, nic, etc) My synology is working like a champ in all other aspects, its only these high bitrate direct streams from PMS that I am having issues. (lower- full bit rate HD blu ray mkv’s play fine)

Seeking support to determine if this is a PMS bug, an inadvertent config issue, a corrupted config issue, something new, something else. But I do know what ever the problem it is specifically coming from the synology pms client on my nas, as I have tested the raminder of the ecosystem to work flawlessly.

Any help appreciated.

Thanks

-Log Attached

Plex Media Server Logs_2020-10-21_DEBUG.zip (5.3 MB) Plex Media Server Logs_2020-10-20_Verbose.zip (5.0 MB)

2

If you’d be kind enough to turn VERBOSE logging off and keeping it off?
Verbose logging is a significant hindrance in most cases. We only use it for tracking server-device debugging of custom devices. In this case, DEBUG provides more than enough which is why it’s the default setting.

Once setting DEBUG on, VERBOSE off,
please recreate until the point of problem.
then stop playback
wait 30 seconds
download the logs
and attach the ZIP please.

3

Thanks for the response @ChuckPa, if you kindly look, I attached both DEBUG and VERBOSE to my OP. I did read the pre-reqs, just thought due to the extremely odd nature of this issue, having the Verbose logs also already available might save a comment/response cycle should they be needed.

Any further help appreciated. Thx.

4

I can see some activity in the end of the logs but it’s not clear what is originating it.

It appears TCL TV is the destination.

What I see from the player side is:

Oct 21, 2020 09:58:42.758 [0x7f7b3ce31700] DEBUG - Request: [192.168.1.189:51950 (Subnet)] GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (10 live) TLS GZIP Signed-in Token (bryan@hunwardsen.com)
Oct 21, 2020 09:58:42.758 [0x7f7b3ce31700] DEBUG - Content-Length is -1 (of total: -1).
Oct 21, 2020 09:58:44.528 [0x7f7b8516f700] DEBUG - WebSocket: client initiated close
Oct 21, 2020 09:58:44.529 [0x7f7b84e81700] DEBUG - NotificationStream: Removing because of close
Oct 21, 2020 09:58:44.566 [0x7f7b84e81700] DEBUG - Auth: authenticated user 1 as bryan@hunwardsen

The player stopped the playback. Did it stop or did you stop it

We’re probably going to need the player logs for this.

I’m asking this because the exact same 64 bit binary image is used for both Linux workstations and for NAS boxes. The only difference is the installation ‘packaging’.

As for network speed. playing 85 Mbps (average) video is on the edge of what TCP/IP can support over 100 Mbps ( 85 Mbps * 1.2 conversion factor = 102 Mbps )

This means it should be able to start playing and play until the bit rate gets into the high end. Those 120-150 spikes, if not sustained or in close proximity, will smooth out by the buffer the app has.

Would you mind giving this a shot so we can see what the TV app sees?

5

I generate some logs for you this weekend, and post here Thanks

6

@ChuckPa I have attached the Client log as well as the Server+Client Debug log from the same session.

I ran 1917 from the start, it made it further than it usually does, had a few small hiccups that where rebuffered quickly but ultimately failed with the network error a couple minutes in, then trying to “retry playback” saw it buffer the stream start playing then drop to the error again almost immediately.

Just to refresh, this is only happening when streaming from the SynoServer, the same movie plays fine from a desktop server both connected to the same switch, and all synology diagnostics I can run show proc, ram, disk and network IO are all at low utilization during the session.

Any help appreciated. ThxPlexSynologyAndTclRokuClient_Debug.log (236.9 KB) PlexTclRokuClient.log (168.9 KB)

7

I really wish you hadn’t truncated the logs the way you did.
You cut out what I needed to see.

we can arrange to send the full logs privately if you prefer but I can’t work with this as it’s incomplete.

You do need to enable automatic database optimization in Scheduled Tasks and perform that optimization once yourself


Oct 27, 2020 11:17:28.127 [0x7fcf05cd7700] Warning - SLOW QUERY: It took 430.000000 ms to retrieve 10 items.

10 items should take about 2 milliseconds

8

I appreciate the help, but I am not sure what you mean by truncating the logs?
I captured the full client log from the moment it was enabled until I had repro’d the issue, I took the server log from nearly the same starting timestamp until completion of the reproduction. Aside from that, I only replaced PII(?)

How long do I have to wait after the repro has occured to capture the full log without it being truncated?

I will run the DB optimization and re-capture the logs, but it would be helpful, as I am very technically competent and trying my best here, to be more specific in requests if more specificity is needed so that it is easier for me to be able to provide support you and the support request in a way that you need.

9

@ChuckPa I want to thank you for your support here! I have been intending to return here with more testing, and log results, but have not had the time.

In the meantime, I have upgraded my wifi Netgear Nighthawk Mesh wich is wifi 6/ax with 802.11s EasyMesh but no dedicated backhaul channel(s) for the mesh network and only 2x2 stream capability… but it IS wifi 6 so I thought it would/should be more than good enough as I have 1 router and 4 satellite nodes throughout a 1000sq ft 2 story house. It should (!!!) have more than enough capability to do the peak bandwidth I have monitored spiking to 150-175Mbps of 1917(directplay uncompressed from 4k bluray-no transcoding). But I was seeing other networking limitations with file transfers and the like and began a 10Gbe/Multi-Gig overhaul of my home network. but before I ran a dedicated hardline from upstairs to downstairs (nightmare) I wanted to go try top end wifi 6 which I have avoided since 6e is coming soon and they all use proprietary backhaul channeling which is not mesh in any strict sense. But I did pick up Orbi AX6000 which has 12 streams on the outward facing and on the backhaul channel.

I did some thorough testing against all of my infra and found MASSIVE performance gains across the board from with a strong 5 bars signal strength vs 4 on the Nighthawk, 2x-5x speed improvement based on client nics and location.
However, when I tried to stream 1917 from syno-plex gigabit hardlined to orbi satellite that is a mere 2 feet from the tcl roku tv connected on its AC wireless, it still would not work. And I again though there was an issue with the syno-plex server, the tcl wireless nic, the tcl processor not being able to handle this high bit-rate HVEC, or possibly the tcl roku plex client.

I then unded up picking up a newer model of the tcls I currently have (3x 2018 R6 series), I got a 2019 R6, just doing some validation testing (it was open box) it the next room over from the syno-plex and orbi satellite, i tried 1917 on it thinking that if it was a tv nic or processor issue, the newer model year may have bumped spec just enough to handle the stream. Well It worked immediately and flawlessly. So i resigneed myself to have to replace all my older TV’s, but on a whim I already had an older tv in the same room, so I tested it connected to the nighthawk which has a hardline connection to the syno-plex and it failed as usual. Then I tried connecting it to the orbi and lo-and-behold even my 2018 model worked just fine.

I had done a similar test in my office when I installed the orbi and it failed, my only guess is that the tv had connected to the router downstairs and not the satellite 2 feet away for some reason causing the network to send it downstairs then back upstairs. I reconnect the 2018 model office TV to the orbi network, and it started playing 1917 flawlessly as well.

So I tried the most critical use case, hoping it might work, syno-plex server sending 1917 downstairs over the Orbi backhaul channel, then having it broacast 10 feet line of sight to the HomeTheater TV. But that is still failing.

I have not given up as I still need to mount my Orbi’s and comepltely remove the nighthawk system from the network. But I think these test results clearly are conclusively ruling out server or client issues!

I again want to express deep appreciation for the support. The NightHawk SHOULD have been able to handle this when everything is in the same room, maybe not to the downstairs TV, but at least the Orbi is making a difference, I may still have to run a backhaul hardline from downstairs to upstairs, but at least I have confidence that If I do put in all that work, it should work as intended and is in my control and not dependant on bug fixes at PLEX end.

Now If I could just get devs to implement DolbyVision for PlexTV client Ill be in heaven for the next 5 years!!!

Have a great holiday @ChuckPa

regards-

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.