Ive already been sitting here messing with things and trying different movies ect. I can restart and just play the one video and get the same results though if that will give a nice neat log to look at. which log file would you want? Just plex Media Server.log or the whole shebang of 138 log files? Ive also got verbose logging turned on at the moment.
When you reboot, after the ‘big boom’, Just go to ‘Settings - Server - Help’ and click Download Logs. It will give you a single ZIP file. Just attach that here. It will give me all I need, precisely as I need to see it.
Ok, not sure what the big boom is. Restarted server. Played a 264 file on an android client with subtitles on. Stuttering (~2 second freeze) .02, 1:14, 2:15, 3:03, 4:14, 5:25 seconds after playback started. Stopped movie and downloaded log files.
Sorry, I was thinking of two things at once and wrote the wrong thing (long day here).
In looking through the log (I forgot to ask you to disable VERBOSE logging if you had it on), it looks like the client you’re doing this on has initiated playback, then goes a certain distance then initiates playback again and seeks to where it wants to be. It makes no sense and isn’t how it works / should work.
If you wouldn’t mind, redo this one more time… DEBUG logging only. Doing so will remove all the protocol and token exchange information with each block and make it easier for me to track.
I’d like to confirm, the Nexus is the player, Android 7.1 ? If not, please let me know. If it is, please continue with the playback, log capture, and upload of the zip file.
OK, restarted and redid test. Resumed video with original quality and subtitles enabled. Yes, Nexus Android 7.1 is the player Im currently testing with. Stutter at 0:09, 0:55, 2:02, 3:00, 3:45. Times might me slightly off because I had a hard time starting the stopwatch.
Got it. Thank you!
If you look in Plex Media Server.log, anywhere near 23:40:38, you can see absolutely normal playback… it runs 100% normal all the way through 23:44 which should be well past the stutters you’re seeing.
From everything PMS is telling me, I see no errors or warnings.
If you wish to look yourself.
Lines like
j:\plex temp\plex-transcode-7638cace562e0c6a-com-plexapp-android-1c62e153-3336-4b72-a210-0fa2689bae4b\media-02462.ts is where PMS is taking the transcoded output and sending it to you. (transcoder wrote to that file).
As I feared, with the processor, you see speed=0.6. That’s transoding at 60% of real time requirement. 1.0 is perfect real-time.
You’re right on the hairy edge of able to burn in the subtitles and get away with it.
Jan 07, 2017 23:40:16.591 [4200] DEBUG - Request: [127.0.0.1:49402 (Loopback)] PUT /video/:/transcode/session/7638cace562e0c6a-com-plexapp-progress=38.0&size=-22&speed=1.2&remaining=3461 (11 live) Signed-in Token (PoppinJ)
Jan 07, 2017 23:40:15.046 [4220] DEBUG - We want 60 segments ahead, last returned was -1 and max is -1.
Jan 07, 2017 23:40:15.046 [4220] DEBUG - It took 0.0 sec to serialize a list with 0 elements.
Jan 07, 2017 23:40:15.046 [3432] DEBUG - Completed: [127.0.0.1:49395] 206 PUT /video/:/transcode/session/7638cace562e0c6a-com-plexapp-android/progress?progress=38.0&size=-22&speed=1.2&remaining=3461 (11 live) 1ms 326 bytes
Jan 07, 2017 23:40:15.470 [4196] DEBUG - Request: [192.168.1.188:38089 (Subnet)] GET /video/:/transcode/universal/session/7638cace562e0c6a-com-plexapp-android/base/02447.ts (10 live) TLS Signed-in
Jan 07, 2017 23:40:15.471 [4196] DEBUG - Asked for segment 2447 from session.
Jan 07, 2017 23:40:15.531 [3476] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Jan 07, 2017 23:40:15.531 [3476] DEBUG - Auth: Came in with the master token, authorization succeeded.
Jan 07, 2017 23:40:15.531 [4208] DEBUG - Request: [127.0.0.1:49396 (Loopback)] PUT /video/:/transcode/session/7638cace562e0c6a-com-plexapp-android/progress?progress=38.0&size=-22&speed=0.6&remaining=4961 (11 live) Signed-in Token (PoppinJ)
Jan 07, 2017 23:40:15.532 [4208] DEBUG - We want 60 segments ahead, last returned was -1 and max is -1.
Jan 07, 2017 23:40:15.532 [4208] DEBUG - It took 0.0 sec to serialize a list with 0 elements.
Jan 07, 2017 23:40:15.532 [3432] DEBUG - Completed: [127.0.0.1:49396] 206 PUT /video/:/transcode/session/7638cace562e0c6a-com-plexapp-android/progress?progress=38.0&size=-22&speed=0.6&remaining=4961 (11 live) 1ms 326 bytes
Jan 07, 2017 23:40:16.096 [3476] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Jan 07, 2017 23:40:16.096 [3476] DEBUG - Auth: Came in with the master token, authorization succeeded.
Jan 07, 2017 23:40:16.097 [4204] DEBUG - Request: [127.0.0.1:49401 (Loopback)] PUT /video/:/transcode/session/7638cace562e0c6a-com-plexapp-android/progress?progress=38.0&size=-22&speed=0.9&remaining=5370 (11 live) Signed-in Token (PoppinJ)
Jan 07, 2017 23:40:16.097 [4204] DEBUG - We want 60 segments ahead, last returned was -1 and max is -1.First off thanks so much for all your help. It’s just so crazy to me that each core never even comes close to 100 percent use during playback, and CPU average hangs around 55 percent. Reference the screenshot posted earlier. It still makes no since that I can transcode any film to any bitrate just fine, but all the sudden with the subtitles on it can’t handle it? I just don’t get it, it’s a 6 core CPU, albeit an older one. Adding subtitles should be no problem.
I agree. It’s behaving as if it’s waiting for data. If you were running out of CPU (crunch) it would be 100%.
Older FX chips kicked Intel’s butt at integer math, which is exactly what this is… a slew of 64 bit SSE2 ops (all integer). This should be a no-brainer. From my first FX-55 through my Opterons, I always ran matched-pair memory. It made a huge difference. Double the data per clock. One clock would fill the whole cache row. It did a great job of making up for the slow AMD FSB.
If you have a hodge podge of memory in there, the MMU will slow the memclock down to that of the slowest latency DIMM, my first attempt would be to get a matched pair (fastest compatible with the Mobo) in a good sized chunk (capacity). Pull the rest of the stuff out and run only that single pair (after running memtest86+ to verify speed, Dual Channel operation, and, most importantly, system stability.
There’s nothing wrong with pushing the FSB clock a notch or two either provided the memory will take it. This is where memtest86+ and matched pair pays for itself in spades.
See where this is going? Inventory time?
I’ll check the memory and all the clocks tomorrow. Maybe I goofed and used a low multiplier or something. I might bump up the overclock tomorrow to see if that helps, but I can’t push it to far because it’s a cheaper Mobo. Plus, with the CPU not maxing out it doesn’t seem like it would help to raise those clocks anyways. I didn’t originally build it to be a Plex server so processing power wasn’t a concern, budget was. Could my Seagate archive HDDs be an issue? I know they have abysmal random access rates, perhaps with it continuously grabbing the subtitle file or something. I wouldn’t think so and I’m pretty sure it does the same thing on my WD Red drives too but I’ll check that as well.
Check the i/o rate on the HD’s. Back compute the math. At 24 Mbps + audio, you’re looking at 4 MB/sec in and another 4 out. If they can’t do that, put a chain on them and use them as anchors
what’s the mobo? I’ll give a quick look at memory for you. Should be really cheap given the era
Ok moved a file to another hard drive and the problem persisted. Memory is a paired dual channel 8GB kit running at1616mhz at 9/9/9/24. Is there any way to run plex from some sort of live linux destro? If so I can eliminate the windows OS entirely and see if that helps, but running in safe mode should have eliminated any OS problems. Im running out of ideas. Ill OC the processor for a quick run and see if that changes the behavior at all.
I am convinced, it is in part the VC-1 video codec and in part the PGS subtitles.
The ‘single thread rating’ of your cpu is 1222 points.
We’ve established in a few tests that you need at least 1350 points of ‘single thread rating’ to get the combination of VC-1 anf PGS subs running fluidly.
Here is a test:
Get Subtitle Edit and let it extract the PGS subtitles from your movie file. Let it convert the subtitles into the SRT format.
Put the SRT file beside your video file. Name it exactly like the video (minus the filename extension, of course).
Then play the file again, but this time select the SRT subtitles. Do you experience a difference?
I’ll test that out tonight and see. I know the one film I picked to show the XML for was VC1 but I have the exact same problem with h264 videos as well. I’ll look into the subtitles though. So far all the ones I’ve played have been PNG and not srt. Ill see if srt makes a difference. I’ll also try bumping the CPU up to 3.6 or so and see if that helps. The Mobo I am using is a 4+1 phase design though and 24/7 at that speed and necessary voltage probably isn’t a good match.
Ok so it appears I have trouble with only with PGS subtitles. I tried 3 movies with SRT subtitles and I had no problems at all. Back to any movie with PGS subtitles and the stuttering started again. Is there a reason PGS subtitles are more difficult? Like 90-95 percent of my movies only have PGS subtitles so Id rather not have to get all new subtitles for everything.
As I understand it, PGS subtitles aren’t text like SRT, they are actual bitmap images. Merging that with video must really cause some CPU hurting. There are some threads about PGS and Plex and performance issues; they might be worth searching for and reviewing.
That is correct. PGS subtitles are bitmap images which must be mapped into the existing. It’s a decode-map-encode operation.
Well I guess problem solved. The CPU just doesn’t seem strong enough for PGS subtitles, even with H264 codec. VC1 is unplayable at with subtitles on which isnt a big deal because less than 1 percent of my library is VC1, most is h264. Ive bumped up the CPU freq and it did help. I can now play H264 files at full blue ray quality with no, or extremely rare stuttering. I hate that no single core even comes close to showing 100 percent, never higher than 80, with total cpu load around 65 percent and yet it still causes my freezing/stuttering problem. My current CPU passmark score is right at 6000, with single core around 1130. I got perfect H264 playback with PGS subtitles with the CPU clock at 3450, but it wasn’t stable and the low end motherboard probably shouldn’t even have a 95w processor in it, much less an overclocked one so the best I can do with it is 3.31Ghz. With this speed I get either no freezing, or a freeze once every 10-15 minutes. The Trans coder was also on Prefer higher quality encoding, and I have changed it to Prefer higher speed trans coding but I noticed little to no difference. Thanks again for all the help and responses.
