Server Version#: 1.18.4.2171
Player Version#: Android 7.26.0.14578 (eaeeea5c)
Good Morning! I’m new to plex, and noticed an issue with only SOME of my videos in my library. For instance, I started streaming a 1080p video file, and after a few minutes, all my players start buffering on local connection.
The developer part of me said “Let’s check the logs!”, and I noticed one call in particular that was failing. For me, it was this, full of identifiers:
So, again with the developer part of me, I used postman to test this call and it it never ends. Eventually, it kills postman (after a few minutes of running).
I know this is probably really technical, but has anyone experienced a problem similar to this? I noticed that if I switch a device to Direct Stream, it works fine… Seems to only be an issue with Direct Play.
I also don’t know how to switch android devices to Direct Stream only, so the android users in my household are S.O.L.
That call is to direct play a file. i.e. it will download the entire file so it doesn’t stop until the file is downloaded or there is a command to stop/pause the download. This is expected.
You don’t. This is done automatically by the app when it’s needed. If you are getting a lot of buffering with direct play, that could mean something on your network isn’t allowing the transfer to work properly.
If you want to provide your log and the time when the buffering starts, I can take a look.
Thanks for the response, @anon18523487! And thank you for the clarification on the API method. I assumed it was only supposed to return a part of the requested video, based on the API name.
Fortunately, I only have to give you a few lines of logs, because this is repeated OVER and OVER and OVER again. I replaced names of files and user names with *, but if you need to know those, I don’t mind sharing the unaltered log.
This happens on Android and Apple Devices (iPhone and Apple TV), but this sample of logs was created when an Android device (S10+) attempted to play the video file.
Jan 10, 2020 21:40:59.052 [0x700007dc2000] Debug — Auth: authenticated user 1 as ****
Jan 10, 2020 21:40:59.052 [0x700007fce000] Debug — Request: [192.168.86.42:39936 (Subnet)] GET /library/parts/4028/1578484660/file.mp4?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=91264 (29 live) TLS Signed-in Token (****) (range: bytes=221270483-)
Jan 10, 2020 21:40:59.060 [0x700007fce000] Debug — Content-Length of /Volumes/***/***/****).mp4 is 4789225301 (of total: 5010495784).
Jan 10, 2020 21:40:59.072 [0x700007dc2000] Debug — Failed to stream media, client probably disconnected after 950272 bytes: 32 - Broken pipe
Jan 10, 2020 21:40:59.072 [0x700007dc2000] Debug — Completed after connection close: [192.168.86.42:39934] 206 GET /library/parts/4028/1578484660/file.mp4?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=91264 (28 live) TLS 79ms 950272 bytes (range: bytes=206358393-)
One thing I did do, and this seems to be a workaround for me, is to create a optimized version at original quality. That has 0 issues with Direct Play, but the original file in my libraries folder will cause the above error in the logs.
As far as network goes, I thought the same thing at first, but it only does it with some files… Most files play just fine. The server is wired in to my LAN, and there’s a clear line of sight between the Google WiFi puck and the device in question, and speed tests on the Google WiFi app show the pucks connection to my device to be running at 391 Mbps.
Basically the Android client requested that file starting at a certain range (which it can do), but something happened and the transfer stopped after it received some of the data. It then requests the file again at the new spot. This is likely repeating which is why you keep seeing these lines in the log. Identifying why the transfers are stopping is hard to determine. A few potential causes are:
1 - QOS on your router interfering
2 - badly encoded file
3 - other network issues
You say that if the file gets transcoded it works fine, which points more towards 2. And your statement that this only happens with some files and not others also point to 2.
I’d be inclined to believe that as well, but the following statements are also true, so it leads me to believe there’s a bug in Plex.
The movie file, when copied manually to devices, plays just fine.
The movie file works in Plex when you force Direct Stream on Apple devices.
To rule out a badly encoded file that Plex doesn’t like, I will go through the steps to re-encode the original file and re-upload to my Plex server. This may take a few days as I’m in the process of converting my movie collection to Plex and don’t want to go out of order, so I don’t miss anything.
I’ll come back in a few days and let you know the results!
The Plex app uses your device’s hardware decoders to playback the file. Using the built in player probably uses software decoders bypassing the hardware so the results would be different.
That also points to a bad file. Direct streaming changes the file, so it may not be the encoding, but the way the file was put together.
Well, after some time @anon18523487, I think I see a common pattern with the error…
Any movie with embedded subtitles has the error. When I run it through the optimizer, it will strip the subtitles from the MP4 and produce the SRT files. After this, the movie will play without error.
Is there a way to send this to Plex to review and potentially address?
