Server Version#: 4.18.1 (raspberry pi 3)
Player Version#: 4.15.2 (Plex for Samsung)
OK so I’m losing my mind here. A series of a TV show, all episodes in the same format, same subtitle options, same audio options, everything in the metadata on the files is identical as best as I can see. Episodes in the first half of the season direct play, the latter half dont! Uploaded a pic from the activity dashboard to show the differences and the logs from running each episode below.
Obviously, on a Pi, transcoding doesn’t work due to CPU limits so as far as I can see this weird bug has made half the series unwatchable for what appears to be no reason? I can jump back and forth between episodes and the pattern is always the same, first half direct play fine (and also all other seasons) just the last few episodes that don’t.
Can you provide the media information for both working and non-working files (collect and upload the XML data for both)? Also, can you provide the full debug logs? The snippets you provided don’t contain the full context and information about how the decision to transcode was made.
Is playback fine? Because “direct stream” of audio should not be causing undo CPU cycles or bad playback. It’s not actually transcoding, just remuxing (for some reason that I don’t see in the screenshot).
Also, what’s the actual server version? You’ve posted the web client version.
I re-uploaded the logs because I realised that I filtered them for the term “direct play” to try to read it myself, full log should be there now?
The playback is fine, no issues that I can see. Even the transcoded episode is adequate when it plays, it just stops to buffer every 5 seconds or so. But on the working episode CPU useage is also sub 10%, closer to 5%.
EDIT: There are 2 audio files for each episode, a standard and a directors commentary (same for both episodes) so that might be the souorce of remuxing the audio in the same way it has to transcode if you apply subtitles?
The biggest difference I see in the media information is the bitrate (of the video stream). For the transcoded example, the H.264 stream bitrate is 3293 Kbps (of the 4212 total); for the working example, it is 2358 (of 3275 total). Do you have any bandwidth limitations for local streaming configured on your client?
As for the logging, it shows this for the media decision:
Dec 23, 2019 00:26:45.674 [0x589fb450] Debug — MDE: Selected protocol dash; container: mp4
Dec 23, 2019 00:26:45.674 [0x589fb450] Debug — MDE: analyzing media item 8817
Dec 23, 2019 00:26:45.674 [0x589fb450] Debug — MDE: E15 - Fry and Leela's Big Fling: Direct Play is disabled
Dec 23, 2019 00:26:45.674 [0x589fb450] Debug — MDE: E15 - Fry and Leela's Big Fling: media must be transcoded in order to use the dash protocol
Dec 23, 2019 00:26:45.674 [0x589fb450] Debug — MDE: E15 - Fry and Leela's Big Fling: Direct Streaming is disabled, so video stream will be transcoded
Dec 23, 2019 00:26:45.675 [0x589fb450] Debug — MDE: E15 - Fry and Leela's Big Fling: no remuxable profile found, so video stream will be transcoded
Dec 23, 2019 00:26:45.675 [0x589fb450] Debug — MDE: Cannot direct stream video stream due to profile or setting limitations
I’m not familiar with the Samsung client, but does it have a setting for enabling/disabling direct streaming? Some clients do; for example, on Roku, it is in the Video settings and is called “Allow Direct Stream.” If you do have this setting, and it is disabled, try enabling it. It appears that for some reason the client is requesting an MP4 container which requires a re-mux. And it also appears that it’s not allowing direct streaming, which forces a the transcode.
I found that setting on the samsung end, disabled and re-enabled it and it hasn’t had any effect. I’ll go around that ride again with a restart inbetween to see if that flushes out any weirdness in the settings.
That line in the log was what caught my attention too, because without making any changes to the setup it goes from direct playing one episode to saying direct play is disabled in the other. Those two logs for the two episodes were taken seconds apart from each other with no changes made to any of the setup in between.
And I’m not sure about the technicalities of the file data etc, but I’d have assumed that the episode with the lower bitrate would be the one that’s MORE likely to be direct played? If the file that was being transcoded had a much higher bitrate then I’d have an idea as to why direct play might be failing, but I’ve looked and set every setting I can find to have no limits / prefer max quality etc where appropriate.
EDIT: To be sure, I disabled Direct Play client side, restarted the client and played the “working” episode, which then transcoded to be played. I re-enabled Direct Play at the client and the working episode went back to Direct Play but the non-working episode still transcodes
Ahhhhhhh OK, I’ll have a look at all the other eps that are transcoding and see if I can spot a commonality there, grand!
Would this mean that (assuming there are no hidden settings in the client or server configs that limit the bitrate) that the problem is likely to be that my TV doesn’t support the file if it’s over a certain bitrate? Because if so, aw beans, but at least that’s an answer I can understand!
I’m not sure. If there were such limitations imposed by the TV, I wouldn’t expect them to be so low.
Check in the Video settings of the Plex client. On the clients with which I’m familiar, there are settings which can limit the max quality (bitrate) for both local and remote streams. Depending on the client they’ll be named “Local Quality”/“Home Streaming” or “Remote Quality”/Internet Streaming." See if you have anything configured the local version and, if so, set it to Maximum.
Client side there are options for Local Quality, Remote Quality and Online Quality, all of which are set to Original (Maximum isn’t an option but I assume it’s functionally the same?)
The relevant page from the TV User Manual is attached, I don’t see any issue but I’m the first to admit that when it comes to codecs and all that chat we’re moving out of my area of expertise entirely!
The only other thing I could guess at is there might be a server-side setting that limits the outgoing bitrate but I can’t see anything to that effect?
Yep, Original is the one you want, at least for local quality. And I’m not aware of any server-side settings which restrict local bandwidth, only remote.
So to try to keep clarity here, the episode that has been working I’ll call A, the episode that hasn’t I’ll call B and this new funnyguys that’ve cropped up I’ll call C and D.
A has a bitrate of 3275
B is 4212
C is 3798
D is 4029
Episodes B and C are the two that transcode, A and D both direct play. So it doesn’t look like bit rate is the issue?
Is that the full log? It seems either filtered or truncated. It doesn’t contain the media decision information I’d expect to see (like what I posted earlier from your logs).
That’s strange, it’s still not there. Try it this way: Navigate to Settings-> Troubleshooting in the web UI and select Download Logs. That should give you a zipped archive with the full log package. Upload that here, or you can DM it to me…
Thanks for the logs. Unfortunately, it doesn’t appear to be logging the media decision in the same manner in the working examples. Perhaps that’s always been the case, but I really thought it did for some reason.
At any rate, I don’t see any reason why it would be able to direct play the files it is, versus the one it is not. The only other significant difference I see in the XML data between them is the number of reference frames listed for the direct playable ones compared to the transcoded examples. In the direct played files, refFrames is 5; for the transcodes files, refFrames is 8. You could have a look at your other files to see if that pattern holds (search for “refFrames=”).
