I’ve got an Xeon based server that is plenty powerful. Plextranscoder never get’s above 9% usage. I can run multiple Rokus, PC’s, Shields, etc at once and never get a hiccup on any of them.
I’m getting a pretty constant spinning buffer symbol and the “We’re having trouble playing this video blah blah blah” message. All my media has been converted to the recommended Plex friendly MP4 files for Direct Play.
@snayers: I’d need the app logs and the media info XML from the file you’re trying to play.
I let the App just sit there and spin for about 10 minutes and it took PMS down completely. I’ll get it restarted and get you some logs in a bit.
@pombeirp said:
@snayers: I’d need the app logs and the media info XML from the file you’re trying to play.
How do you want me to get you the logs file .zip?
You can send me a direct message
Anyone else has feedback to provide regarding the change in 3.0.41? In the end, if it made things worse for users, I’ll revert the changes.
@pombeirp said:
Anyone else has feedback to provide regarding the change in 3.0.41? In the end, if it made things worse for users, I’ll revert the changes.
Sadly I’m at work now. Didn’t even think to look earlier today…Because I didn’t see an announcement in the release announcements thread I just assumed the update hadn’t landed yet. Was not announcing it deliberate or just an oversight? 
Anyway as soon as I get home off nights I have plenty of DTS and DTS-HDMA to test out.
@davehobson it was an oversight. I was sure I had posted the release there. Thanks for pointing that out, and looking forward to your feedback.
@pombeirp said:
Anyone else has feedback to provide regarding the change in 3.0.41? In the end, if it made things worse for users, I’ll revert the changes.
I went from having slight stuttering/hiccups in audio (about once or twice a file, usually near the start or whenever i skip ahead or backwards) to having about every second file hang on me part way through. Prior to the forced transcode of AC3 streams, most of my media was being DirectPlayed, now almost every single file gets transcoded and the transcoder is a broken piece of ■■■■. It never goes about ~20% cpu usage and never more than ~100 MB of RAM usage (often quite less) with total system usage around 35% cpu and 65% RAM, so I know it’s not a matter of resource availability. Yet without fail every second or third file played in a row will result in the transcoder either going to sleep when it creates a buffer and then not waking back up, or the transcoder out right terminating its own process (resulting in a video stream that terminates with upwards of 1/3 of the file left to play.
Same problem for many 720p & 1080p videos on Surface Pro 4, and many 1080p videos on i5 4690/8GB desktop PC.
Both devices have Windows 10 Redstone 1 version.
I’m 100% sure it’s not about network capacity. Plex client on iPhone works perfectly.
Please help!
Same here, posted on the other topic and it got really bad since last update. It wasn’t great before but now it’s unusable.
@aroth.khashar you’re right that there might be a problem in the transcoder (at least that’s what this other thread seems to imply. Will ask the responsible dev regarding the transcoder, but it is looking like the best thing for now is to revert the multi-channel AC-3 transcoding and just live with the possible stuttering on lower end machines until we can replace the video player stack.
@aroth.khashar Maybe the issue is that the client app isn’t able to update the server to tell it how the playback is going, so eventually the session just times out and the server stops transcoding. See https://forums.plex.tv/discussion/228065/pms-transcoder-doesnt-work-correctly-with-windows-10-plex-app
Would be interesting to get the logs (both client and server logs) to confirm this.
@aroth.khashar what hardware are you running your PMS on, out of curiosity?
@pombeirp said:
@aroth.khashar what hardware are you running your PMS on, out of curiosity?
Sorry for the delay in the response. Running PMS on an AMD FX6300 (3.50 GHz) with 8 GB of ram. Operating system is Windows 10 Pro x64 (November Update). Plex App is running on the same system, and I have noticed in the logs that PMS will randomly swap its connection from 127.0.0.1 to 192.168.1.120. The 1.20 address is the LAN IP for the desktop itself. I have included the logs for both Plex and Plex Media Server. The most recent file played has actually seen the transcoder shut down twice during playback.
What I notice happening is that the “buffer” seems to shrink and not start growing again. When I see this, usually 2 out of 3 times if I check my task manager, there is no instance of PlexTranscoder.exe running. The third time will usually see PlexTranscoder.exe sitting idle in my task manager, using 1-2% of my CPU and a few KB of RAM (if that), with a total system load of around 5-10% of the CPU and ~55% of the RAM. If I fail to notice the shrinking buffer, one of two things will happen. Either the file will time out during playback when it reaches the end, and start displaying the loading circle, or it will terminate the file as if it reached the end and start queuing the next file in the playlist.
edit:
Happened a third time on the same file shortly after posting this. Notice in the screenshot that the buffer does not extend all the way to the end of the file, and yet there is no instance of PlexTranscoder.exe in the Task Manager.
Thanks for the great insight @aroth.khashar. I’ll keep an eye on that.
FWIW, 3.0.43 released today reverts the decision to transcode multi-channel AC-3. This just means we’ll have to wait for the revamp of the video player stack for a definitive fix.
Idk what happened, but not the app won’t work at all after trying to update it.
“An unexpected error has occurred. The developer has been notified of the problem.”
@aroth.khashar the log shows you’re on 3.0.43. Have you tried updating to the latest 3.0.46?
@pombeirp said:
@aroth.khashar the log shows you’re on 3.0.43. Have you tried updating to the latest 3.0.46?
That post was from shortly after 3.0.43 was pushed. The update to 3.0.45 fixed my issue, as discussed in the thread for that problem. Currently on 3.0.46 with no issues.
@pombeirp said:
This just means we’ll have to wait for the revamp of the video player stack for a definitive fix.
Do you know when this is supposed to happen?
