Synology + AppleTV after DSM7 - Connection to server not fast enough

Server Version#:1.26.2.5797
Player Version#: 8.1.1 (2466)
Server hardware: Synology RS2818RP+
DSM Ver: 7.1 - 42661 Update 2
Player hardware: AppleTV 4K

Hi, we have 2 Separate plex servers which I have updated from DSM 6 to 7. The first (a Synology FS2017) was successful after a few issues were ironed out but the second will no longer play any media. I receive the message “Your connection to the server is not fast enough to stream this video. Check your network or reduce the quality”.

The plex server shows it is buffering. We do not transcode and have always direct played. The media is not trying to transcode now - it is still struggling to play via direct play.

If I try and stream SD media the issue is still there but not as bad (the media will play but pause to buffer regularly).

To be clear there were no issues prior to upgrading to DSM7 and no other changes have been made to the settings or to the network.

Here is a log I have just taken:

Plex Media Server Logs_2022-06-02_10-24-18.zip (4.9 MB)

Any help please?

Anyone?

This is not good and will cause the network performance problems you’re seeing.

Jun 02, 2022 09:58:24.868 [0x7f1c61203b38] DEBUG - CERT: incomplete TLS handshake from [::ffff:10.26.45.31]:57923: stream truncated
Jun 02, 2022 09:58:24.935 [0x7f1c61226b38] WARN - [CERT] TLS connection from [::ffff:10.26.45.31]:57924 came in with unrecognized plex.direct SNI name '10-26-45-6.74b367eac33141e5ad75aa83db65614f.plex.direct'; using installed plex.direct cert
Jun 02, 2022 09:58:24.964 [0x7f1c61203b38] DEBUG - CERT: incomplete TLS handshake from [::ffff:10.26.45.31]:57924: stream truncated
Jun 02, 2022 09:58:25.108 [0x7f1c5e94ab38] DEBUG - Request: [10.26.150.68:57180 (WAN)] GET /statistics/bandwidth?timespan=6 (17 live) TLS GZIP Signed-in Token (project413) (Chrome)
Jun 02, 2022 09:58:25.112 [0x7f1c61226b38] DEBUG - Completed: [10.26.150.68:57180] 200 GET /statistics/bandwidth?timespan=6 (17 live) TLS GZIP 4ms 2133 bytes (pipelined: 120)
Jun 02, 2022 09:58:25.605 [0x7f1c61203b38] WARN - [CERT] TLS connection from [::ffff:10.26.45.50]:63778 came in with unrecognized plex.direct SNI name '10-26-45-6.74b367eac33141e5ad75aa83db65614f.plex.direct'; using installed plex.direct cert
Jun 02, 2022 09:58:25.635 [0x7f1c61226b38] DEBUG - CERT: incomplete TLS handshake from [::ffff:10.26.45.50]:63777: stream truncated
Jun 02, 2022 09:58:25.858 [0x7f1c61203b38] DEBUG - CERT: incomplete TLS handshake from [::ffff:10.26.45.50]:63778: stream truncated
Jun 02, 2022 09:58:25.956 [0x7f1c61203b38] DEBUG - CERT: incomplete TLS handshake from [::ffff:10.26.45.32]:62562: stream truncated
Jun 02, 2022 09:58:26.026 [0x7f1c61203b38] WARN - [CERT] TLS connection from [::ffff:10.26.45.32]:62563 came in with unrecognized plex.direct SNI name '10-26-45-6.74b367eac33141e5ad75aa83db65614f.plex.direct'; using installed plex.direct cert
Jun 02, 2022 09:58:26.039 [0x7f1c5e9afb38] DEBUG - Request: [10.26.150.68:57180 (WAN)] GET /statistics/resources?timespan=6 (17 live) TLS GZIP Signed-in Token (project413) (Chrome)
Jun 02, 2022 09:58:26.041 [0x7f1c61226b38] DEBUG - Completed: [10.26.150.68:57180] 200 GET /statistics/resources?timespan=6 (17 live) TLS GZIP 1ms 955 bytes (pipelined: 121)
Jun 02, 2022 09:58:26.047 [0x7f1c61203b38] DEBUG - CERT: incomplete TLS handshake from [::ffff:10.26.45.32]:62563: stream truncated
Jun 02, 2022 09:58:26.054 [0x7f1c61226b38] WARN - [CERT] TLS connection from [::ffff:10.26.45.32]:62565 came in with unrecognized plex.direct SNI name '10-26-45-6.74b367eac33141e5ad75aa83db65614f.plex.direct'; using installed plex.direct cert
Jun 02, 2022 09:58:26.071 [0x7f1c61203b38] DEBUG - CERT: incomplete TLS handshake from [::ffff:10.26.45.32]:62564: stream truncated
Jun 02, 2022 09:58:26.079 [0x7f1c61226b38] DEBUG - CERT: incomplete TLS handshake from [::ffff:10.26.45.32]:62565: stream truncated
Jun 02, 2022 09:58:26.109 [0x7f1c5e94ab38] DEBUG - Request: [10.26.150.68:57180 (WAN)] GET /statistics/bandwidth?timespan=6 (19 live) TLS GZIP Signed-in Token (project413) (Chrome)
Jun 02, 2022 09:58:26.114 [0x7f1c61226b38] DEBUG - Completed: [10.26.150.68:57180] 200 GET /statistics/bandwidth?timespan=6 (19 live) TLS GZIP 4ms 2151 bytes (pipelined: 122)
Jun 02, 2022 09:58:26.659 [0x7f1c5e9f0b38] DEBUG - Request: [10.26.150.68:57180 (WAN)] GET /status/sessions (19 live) TLS GZIP Signed-in Token (project413) (Chrome)
Jun 02, 2022 09:58:26.659 [0x7f1c5e9f0b38] DEBUG - [Now] Adding 1 sessions.

I looked at your Plex.tv account.

While your certificate looks OK, it’s the same certificate used in DSM 6. (should not matter)

I did reset your certificate so we can start fresh.

Please restart the server so it can get a new certificate

Please retest and advise the status.

Thanks for the reply ChuckPa.

Have restarted and the issue remains. Can I confirm that you reset the certificate for the account that started the thread and not the second comment’s account as they are different? (I was signed in with another Plex account at the time of writing the reply and didn’t realise).

Attached is the log after the server restart.

Plex Media Server Logs_2022-06-06_15-05-56.zip (2.8 MB)

Looking at the devices accessing this server,

How old is that “Plex for Android” named “Bike” ?

Plex.tv shows it reporting as Plex for Android Android 4.13.0.448
which is ridiculously old

Which device is this please? 10.26.45.43

Its a plex app on a technogym bike, it was added a couple of years ago but I cant think of the last time it was looked at tbh.

10.26.45.43 is an appleTV that is used as a player. To my knowledge that would not have been used recently. In the latest log the device I was using to try and play a movie was 10.26.45.62

Is the ATV (10.26.45.43) the same ATV which is causing you problems?

No, all appleTVs are showing the same problem. After updating the server I have had to log out and log back in on each device. I’ve only logged in on maybe three or four but they are all showing the same issue so I havent spent the time on all others as it seems a waste of my time at this point.

Logging out and back in – or – Forcibly restarting the app ?

Logging out / in isn’t as effective as force terminating it and restarting.

Also, how are they connected ? WiFi ? (if WiFi, 2.4 or 5?)

just logged out and in as the library was not showing in the device app after the server update. The library showed after logging back in. The only issue now is seemingly the speed of the stream.

They are all wired, not wireless.

They were working perfectly before the DSM 7 update.

DSM 7 doesn’t make any difference here unless the network port usage changed.

When the DSM 6 “Plex” shared folder is upgraded, I take the entire “Plex Media Server” from “Plex”, process down through the metadata, then move it (as a whole block) to “PlexMediaServer/AppData”

That said, did you upgrade Plex from 6 to 7 or is 7 a fresh install?

Its an upgrade from DSM 6 to 7.

There have been no other changes at all except the update. It was working perfectly before.

We have another server which was also updated, that is working fine (after a few issues along the way). The only difference is that is a different model synology and the players are over wifi.

Confused by these two statements

Are the AppleTVs wired or wireless ??

The other server which has no issues is a different model and the players are wifi.

The server with the issue has all wired connections.

Doing a little digging…

  1. Your FS2017 is a Xeon CPU - 10170 Passmarks

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+D-1541+%40+2.10GHz&id=2718

  1. Your RS2818+ is an Atom CPU - 1756 passmarks

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Atom+C3538+%40+2.10GHz&id=3253

Now to come back through the actual playback logs on the C3538.
The xeon will power right through all of this. The small Syno (I have a DS1815+ with the 2538 CPU – which is even weaker) can’t do everything the Xeon can.

With the smaller CPU - rule of thumb “One task at a time” – e.g.

  1. Play media
  2. Scan / add / analyze new media
  3. Run maintenance tasks
Jun 02, 2022 09:55:49.072 [0x7f1c5d892b38] DEBUG - [Universal] Using local file path instead of URL: /volume1/Plex/TV Shows/11 Test/11TLK.mkv
Jun 02, 2022 09:55:49.072 [0x7f1c5d892b38] DEBUG - TPU: hardware transcoding: final decoder: , final encoder: 
Jun 02, 2022 09:55:49.072 [0x7f1c5d892b38] DEBUG - [JobRunner] Job running: FFMPEG_EXTERNAL_LIBS='/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData/Plex\ Media\ Server/Codecs/994f4ee-4302-linux-x86_64/' X_PLEX_TOKEN=xxxxxxxxxxxxxxxxxxxx "/volume1/@appstore/PlexMediaServer/Plex Transcoder" -codec:1 dca -analyzeduration 20000000 -probesize 20000000 -i "/volume1/Plex/TV Shows/11 Test/11TLK.mkv" -filter_complex "[0:1] aresample=async=1:ocl='5.1':rematrix_maxval=0.000000dB:osr=48000[0]" -map "[0]" -metadata:s:0 language=eng -codec:0 flac -b:0 4096k -f flac -map_metadata -1 -map_chapters -1 -t 3547.6695 "/var/packages/PlexMediaServer/shares/PlexMediaServer/AppData/Plex Media Server/Cache/Transcode/Detection/54a382c7-1535-46f6-9bab-063789f1434c" -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress
Jun 02, 2022 09:55:49.076 [0x7f1c5d892b38] DEBUG - [JobRunner] Jobs: Starting child process with pid 7364
Jun 02, 2022 09:55:49.117 [0x7f1c5e388b38] DEBUG - Request: [127.0.0.1:49508 (Loopback)] PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress?status=startup (16 live) Signed-in Token (project413) (Flying Fox) (range: bytes=0-) 
Jun 02, 2022 09:55:49.117 [0x7f1c61226b38] DEBUG - Completed: [127.0.0.1:49508] 204 PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress?status=startup (16 live) 0ms 203 bytes (pipelined: 1) (range: bytes=0-) 
Jun 02, 2022 09:55:49.120 [0x7f1c5fe90b38] DEBUG - Request: [127.0.0.1:49508 (Loopback)] PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress?status=startup (16 live) Signed-in Token (project413) (Flying Fox) (range: bytes=0-) 
Jun 02, 2022 09:55:49.120 [0x7f1c61226b38] DEBUG - Completed: [127.0.0.1:49508] 204 PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress?status=startup (16 live) 0ms 203 bytes (pipelined: 2) (range: bytes=0-) 
Jun 02, 2022 09:55:49.120 [0x7f1c5e388b38] DEBUG - Request: [127.0.0.1:49508 (Loopback)] PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress?status=opening (16 live) Signed-in Token (project413) (Flying Fox) (range: bytes=0-) 
Jun 02, 2022 09:55:49.120 [0x7f1c61226b38] DEBUG - Completed: [127.0.0.1:49508] 204 PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress?status=opening (16 live) 0ms 203 bytes (pipelined: 3) (range: bytes=0-) 
Jun 02, 2022 09:55:49.121 [0x7f1c5fe90b38] DEBUG - Request: [127.0.0.1:49508 (Loopback)] PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress?status=opened (16 live) Signed-in Token (project413) (Flying Fox) (range: bytes=0-) 
Jun 02, 2022 09:55:49.122 [0x7f1c61226b38] DEBUG - Completed: [127.0.0.1:49508] 204 PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress?status=opened (16 live) 0ms 203 bytes (pipelined: 4) (range: bytes=0-) 
Jun 02, 2022 09:55:49.122 [0x7f1c5e388b38] DEBUG - Request: [127.0.0.1:49508 (Loopback)] PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress/stream?index=0&id=0&codec=h264&type=video (16 live) Signed-in Token (project413) (Flying Fox) (range: bytes=0-) 
Jun 02, 2022 09:55:49.122 [0x7f1c61226b38] DEBUG - Completed: [127.0.0.1:49508] 200 PUT /video/:/transcode/session/b21c4e5c-e7b7-4d29-9ab3-19501e085a7b/7de3879b-1d5d-4cdd-a455-f1ec4c4a51a2/progress/stream?index=0&id=0&codec=h264&type=video (16 live) 0ms 195 bytes (pipelined: 5) (range: bytes=0-) 

while this is running, it’s also scanning directories for new media.

it’s running through your entire media collection - which is unnecessary.
You can enable “Partial Scan” in Settings - Library to save a lot of CPU time and unnecessary checks.

Surely scanning for new media is not that CPU intensive? Regardless I disabled it and the issue remains.
This was always enabled previously and there were no issues.

Also we have previously tested this setup with 10+ direct play streams at the same time and it worked with no issues. I’m currently only trying with one.

I checked the CPU usage when I first saw the problem - when playing and it initially spikes at 20% then settles around 3% while the movie is trying to play so doesn’t look to be the issue.

CPU Load

ChuckPa - I note there is a new Plex server build (1.27.0.5878-8f821a871) that was released yesterday. I was just about to try this but note the filename when downloaded is lexMediaServer-1.27.0.5878-8f821a871-x86_64_DSM6

The last one I installed was named lxMediaServer-1.26.2.5797-5bd057d2b-x86_64_DSM7

Can you please confirm that this is still OK for DSM 7?

The DSM 6 package is for DSM 6 only ; as is the DSM 7 for DSM 7 only.

The internal format of packages changed between DSM 6 and DSM 7.
They are not interchangeable

On the Downloads page, you’ll find “Synology” and “Synology DSM7”.
You want the “Synology DSM7” versions

My mistake. I’ve installed the correct updated one now anyway but still in the same position.

Any further ideas? This surely has to be an issue between DSM7 and the Plex app as the CPU is not being taxed at all.

I’ve been trying to replicate how this could be happening.

By definition,

  • if all wiring is gigabit - which yields 83 MB/sec (800 Mbps typical )
  • If WiFi 5Ghz is 802.3n - which is 300 Mbps rate (150 Mbps typical)
  • Most newer WiFi (5 Ghz) units now provide 802.3ac (1100 Mbps rate)

There is nothing which should be causing this.

I’ve gone so far as to connect using wired on fast ethernet (100 Mbps link) and still can’t replicate.

There must be something in your LAN topology which is otherwise insignificant but somehow causing this.

Check your link lights ? Make certain they are actually getting the right speed?

Also you can get speedtest for the AppleTV. It will confirm the device itself is seeing the receive bandwidth it should.