I’m trying to diagnose a remote stream issue that is occuring only with a single movie title, or at least only one known movie title.
When a friend attempts to play the title from my server, which is a 1080p 4.5 Mbps title (as indicated by the Plex server Info display), the server is sending data to the remote client at between 130 Mbps and 200 Mbps, and the remote client just displays the spinning icon and is not able to play the stream. The Plex player on his TV says under Playback Settings: “Quality - Play Original Quality - Detected as 93 Mbps”. For Quality selection option on the player, it shows “Play Original Quality - 5.5 Mbps (about 2 GB per hour)”
The bandwidth being consumed is shown in multiple places; on the Windows network resource display where the Plex Media Server app shows it is sending 12 MBps (120+ Mbps) bandwidth, the Plex Dashboard showing between 100 Mbps and 200 Mbps remote user bandwidth, and my router showing that it is sending out between 100 Mbps and 200 Mbps out of the Internet port.
If I play the stream at my house, which is still a remote connection due to the player being on a different VLAN than the server, the bandwidth used is only about 5 Mbps, which is the expected. My player is a newer model Roku device also using Direct Play for audio and video.
The remote client experiencing the issue is a Sony Bravia smart TV, which is listed as Bravia VH21 using the Android platform. The client is attempting to play the title using Direct Play video and audio.
If the remote client forces the stream to 720p, then the server transcodes the title and the stream is delivered at <5 Mbps as expected. The issue only occurs when the client requests the title using Direct Play for video and audio. Changing the audio format to a different option doesn’t change the issue.
Not that it should matter, but the remote client is using the same Internet provider that I have and only lives a few doors from me.
My Internet speed is 1 Gbps for both upload and download and my friend’s service is 500 Mbps for both upload and download.
I am using server version 1.32.5.7349, which is the latest available.
I have enabled verbose logging on the server, but nothing stands out as being out of the ordinary.
Has this issue been seen and/or resolved by anyone else?
If this is a mp4 file, see: Help: stream is constantly buffering, libmpv sends TCP RESET - #2 by OttoKerner
P.S. an initial spike is fully expected, because at playback start the client is filling its network buffer as fast as it can.
Only if the bandwidth remains abnormally high over almost the whole file, refer to the link above.
Thanks for the quick reply. The issue wasn’t the initial buffering spike. The issue is that it wasn’t settling down. From what I could discern from the logs, it may have been that the Android client was having a connection reset and then a re-start/re-buffer, so it just stayed at the initial spike transfer rate.
I did a basic re-encoding of the file using FFMPEG and it works fine, although arguably the video quality might be a little lower and the file size is about 80% of the original. Interestingly, I only observed the issue with the Android client and not with other clients (eg. Web, iOS, Roku).
Ultimately, I went back and re-encoded the original file with Handbrake and it also working.
One other issue that is appearing with the re-encode is that when looking at the playback on the dashboard, with the original file, I could hover over the playback window and see occasional updates, about one every couple of seconds or so. With both re-encodes, it is just a static image that doesn’t show periodic frames being displayed at the client. I’m not sure what would cause that difference.
Follow the link above. It explains how you can repair the file without the need to re-encode and thus lowering the quality.
That’s expected. The video preview thumbnails need to get recreated for the new file. Usually automatically during server maintenance at night.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
