I am running a full server as my Plex Server. Trying to play one movie and transcoding the one video now is killing my server. I have never had this issue before the latest update. I have had 5 devices playing movies simultaneously before and my server didn’t even flinch. Now I can’t play one movie without it locking up. What is going on?
Specs: Dual quad core Xeon processors, 16 GB RAM, 4 TB drives.
I did some more investigating and restarted the server this morning. Everything started to work great again, until we tried to stream to Chromecast, or Visio smart TV. Playing from phones works flawlessly now, but I’m sure that will change. I have attached the logs after restart with only trying to cast to Chromecast and Visio TV. Both Max out the CPUs trying to play only one video at a time.
Update: I played a 30 minute movie on the Visio TV and it played just fine. Tried to play it again about an hour later and CPU stays at 100% until transcoder faults and video is dropped on TV. This is what looks to be happening like a domino effect getting worse throughout the day.
Update 2: Other Videos will peg the CPUs at 100% for about 5-10 minutes then run like a champ at 2% after that.I know there is a spike in the process but 5-10 minutes?
Sorry for the delay… Ok Here is what I have
-
Movie Title: Gummi Bears 1-5 - This movie has played for the past 2 years without issue:
*Played at 9:42 AM
*PlexTranscoder (32 bit) usage - 99% CPU / PlexTranscoder.exe
*Plex will not hold CPU at 100%, App becomes unresponsive and force closes PlexTranscoder.exe -
Movie Title: Monster High Scarrier reef - This movie as well has played for the past 2 years without issue:
*Played at 9:45 AM
*CPU usage during start and play 0-2%
Thank you for your help!
Cory D.
Sir, I restarted the server played those 2 movies and then pulled the log file just as you requested.
I did not wait 2 hours to pull the log files. The time that I played the movies was 9:42 AM, if you look at my post it was 10:17 AM.
The Original movie IS indeed coded in DVD-H.264-AAC…
And as far as the sample that I sent I used one of the methods that was suggest in the link that you provided. The sample that I sent you STILL did the 99% CPU usage. I tested it (as suggested) to ensure that the problem would reoccur.
This is what I was talking about. It can be said that it is wrong format, but how was I able to play these movies for 2 years without issue but now it is a format issue?
IF the sample that I sent you did in deed play fine without issue on your setup, then would it be safe to say that it is something in my Plex configuration?
If you look at the time stamp on the .rar file you will see that it was created at 9:49 AM, 7 minutes after starting the first movie.
Vizio Sigma - V1.5.6-UHD
Plex Version - 3.8.0
This issue happens on Chromecast as well. Casting from Andriod Samsung Galaxy 7 Phone (updated app)
! General
! Complete name : F:\ServerFolders\Videos\Kids Movies\Gummi Bears\Gummi Bears 1x05 - Can I Keep Him [DVD-H.264-AAC].mp4
! Format : MPEG-4
! Format profile : Base Media
! Codec ID : isom (isom/avc1)
! File size : 70.0 MiB
! Duration : 11 min 12 s
! Overall bit rate mode : Variable
! Overall bit rate : 873 kb/s
! Encoded date : UTC 2007-09-02 03:47:45
! Tagged date : UTC 2007-09-02 03:47:45
!
! Video
! ID : 1
! Format : AVC
! Format/Info : Advanced Video Codec
! Format profile : High@L5.1
! Format settings, CABAC : Yes
! Format settings, RefFrames : 6 frames
! Codec ID : avc1
! Codec ID/Info : Advanced Video Coding
! Duration : 11 min 12 s
! Bit rate : 801 kb/s
! Maximum bit rate : 1 980 kb/s
! Width : 560 pixels
! Height : 416 pixels
! Display aspect ratio : 4:3
! Frame rate mode : Constant
! Frame rate : 23.976 (24000/1001) FPS
! Color space : YUV
! Chroma subsampling : 4:2:0
! Bit depth : 8 bits
! Scan type : Progressive
! Bits/(Pixel*Frame) : 0.143
! Stream size : 64.3 MiB (92%)
! Title : Video
! Writing library : x264 core 54 svn-654
! Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x133 / me=hex / subme=6 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=1 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=801 / ratetol=1.0 / rceq=‘blurCplx^(1-qComp)’ / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30
! Encoded date : UTC 2007-09-02 03:47:45
! Tagged date : UTC 2007-09-02 03:47:48
!
! Audio
! ID : 2
! Format : AAC
! Format/Info : Advanced Audio Codec
! Format profile : HE-AAC / LC
! Codec ID : 40
! Duration : 11 min 12 s
! Bit rate mode : Variable
! Bit rate : 68.5 kb/s
! Maximum bit rate : 81.9 kb/s
! Channel(s) : 2 channels
! Channel positions : Front: L R
! Sampling rate : 48.0 kHz / 24.0 kHz
! Frame rate : 23.438 FPS (1024 SPF)
! Compression mode : Lossy
! Stream size : 5.49 MiB (8%)
! Title : English
! Language : English
! Encoded date : UTC 2007-09-02 03:47:48
! Tagged date : UTC 2007-09-02 03:47:48
!
!
OK, here are my notes:
GB 1-5 played at 8:51 PM - Timed out after 30 Seconds
MH Scarrier reef played at 8:54 PM - Played for 2 minutes
Even with the Transcoder quality set to Automatic it still hold CPUs at 99% for the 30 seconds until it times out
- Handy Handbrake Guide in my signature.
- Level 4.1 is plenty
- 4 Reference Frames is plenty
- AAC 2.0 LC is more likely to Direct Play on nearly everything, while AAC 5.1 is more likely to explode on everything as is ANY AAC at ANYTHING other than LC (Main=The Makings of a Great Train Wreck). AC3 5.1 is quite compatible, but YMMV.
- Plex’s Transcoder is a bit Mentally Retarded. Use it at your own risk. Yes, it’s been more Mentally Retarded lately than usual. Perhaps it’s sniffing a better grade of glue - who knows.
and
- Anytime you’ve got your CPU slammed up against the wall frisking it for contraband, you’d better make sure you have good airflow. I mention this because not two hours ago I performed the bi-monthly maintenance on mine, have it slammed up against the wall right now with a couple of Handbrake jobs and it’s running at 158F - system reports all is well.
First I would like to thank you for your time on this.
I guess the biggest question is this. Why is this just now happening? I have had these movies for a couple years and Plex never balked at playing them… Until now.
I have quite a few other movies that do this as well, so it’s not just this one. I used it as the example because my daughter wanted to watch Gummi Bears and now it won’t play at all.
So without going through and figuring out which of the 4000+ videos need converting … What can I do to make Plex “play nice and like” playing these movies seamlessly again?
Again, thank you for all your help!
So… The Chromecast(s) I had before I started using Plex. They were the reason I found and started using Plex almost 4 years ago. I searched for media players and Boom, Plex was there and I haven’t looked back since. The Vizio TV was purchased 2 years ago and until now has really had no issues playing anything.
If re-encoding is required from here out (which is fine, just wish there was a heads up), is hand break the best choice for taking on this task? If I’m going to do a mass conversion I would like to do it now before I get to your level 
.
I will take you up on the advise of checking for damaged files. I thought about that before and figured that I would just replace them as I came across them.
Any other idea on how to optimize My Plex server? Being in IT I don’t like half-assing a solution. All or go home for me.
You should probably closely inspect the settings of the Plex app in that TV. If it ever updated, or if the Gods of Murphy struck, the settings that used to work for years may have leaped back to the defaults. If it’s possible you could also check to see if that Plex app can be upgraded. With Plex upgrading regularly, outdated apps rarely work for long if they too are not updated.
Trumpy’s suggestion of a real device plugged into that TV with a real updated app loaded on it is one I can’t recommend highly enough myself even though I’m sitting here right now with two devices basically bricked - one by it’s manufacturer (Roku) unable to develop stable FW for snot (they’re ‘working on it’ - so they say) - and the other by the AFTV Plex App Development Team that went for a walk in the woods and was never seen from again - that mystery yet to be solved (I suspect the Big Bad Wolf).
@Cdkrash said:
OK, here are my notes:GB 1-5 played at 8:51 PM - Timed out after 30 Seconds
MH Scarrier reef played at 8:54 PM - Played for 2 minutes
Even with the Transcoder quality set to Automatic it still hold CPUs at 99% for the 30 seconds until it times out
I would suggest separating the two issues
- Errors and Timeouts
- High CPU Usage when transcoding
It is possible that both are caused by the same underlying problem - but I would recommend first concentrating on the errors and timeouts and getting samples that exhibit the same failures.
So for example in this last test you had a timeout after 30 seconds
The logs show WAN connection requesting the media and the DASH protocol is used
It shows a number of requests completing ok but then the device app is reporting an error.
This extract shows the requests for the DASH segments being completed ok
Jul 23, 2017 20:51:27.187 [4944] DEBUG - Request: [24.178.185.175:55756 (WAN)] GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/0/initial.mp4 (20 live) GZIP Signed-in
Jul 23, 2017 20:51:27.187 [3968] DEBUG - Completed: [24.178.185.175:55756] 200 GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/0/initial.mp4 (20 live) GZIP 3ms 789 bytes (pipelined: 2)
Jul 23, 2017 20:51:27.187 [4436] DEBUG - Request: [24.178.185.175:55736 (WAN)] GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/1/initial.mp4 (20 live) GZIP Signed-in
Jul 23, 2017 20:51:27.187 [3968] DEBUG - Completed: [24.178.185.175:55736] 200 GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/1/initial.mp4 (20 live) GZIP 2ms 743 bytes (pipelined: 19)
Jul 23, 2017 20:51:27.437 [4944] DEBUG - Request: [24.178.185.175:55737 (WAN)] GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/1/0.m4s (20 live) GZIP Signed-in
Jul 23, 2017 20:51:27.453 [2984] DEBUG - Request: [24.178.185.175:55759 (WAN)] GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/0/0.m4s (19 live) GZIP Signed-in
Jul 23, 2017 20:51:27.469 [3968] DEBUG - Completed: [24.178.185.175:55737] 200 GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/1/0.m4s (19 live) GZIP 35ms 69923 bytes (pipelined: 19)
Jul 23, 2017 20:51:27.687 [3968] DEBUG - Completed: [24.178.185.175:55759] 200 GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/0/0.m4s (19 live) GZIP 236ms 591979 bytes (pipelined: 2)
Jul 23, 2017 20:51:27.687 [4436] DEBUG - Request: [24.178.185.175:55738 (WAN)] GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/1/1.m4s (19 live) GZIP Signed-in
Jul 23, 2017 20:51:28.000 [4944] DEBUG - Request: [24.178.185.175:55736 (WAN)] GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/0/1.m4s (17 live) GZIP Signed-in
Jul 23, 2017 20:51:28.165 [3972] DEBUG - Completed: [24.178.185.175:55738] 200 GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/1/1.m4s (18 live) GZIP 466ms 70640 bytes (pipelined: 16)
Jul 23, 2017 20:51:28.290 [3968] DEBUG - Completed: [24.178.185.175:55736] 200 GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/0/1.m4s (18 live) GZIP 280ms 1272758 bytes (pipelined: 20)
Jul 23, 2017 20:51:28.509 [4944] DEBUG - Request: [24.178.185.175:55737 (WAN)] GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/1/2.m4s (18 live) GZIP Signed-in
Jul 23, 2017 20:51:28.775 [4436] DEBUG - Request: [24.178.185.175:55756 (WAN)] GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/0/2.m4s (19 live) GZIP Signed-in
Jul 23, 2017 20:51:29.072 [3968] DEBUG - Completed: [24.178.185.175:55737] 200 GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/1/2.m4s (19 live) GZIP 560ms 72740 bytes (pipelined: 20)
Jul 23, 2017 20:51:29.322 [3968] DEBUG - Completed: [24.178.185.175:55756] 200 GET /video/:/transcode/universal/dash/7s6te8qj8y0b68xjjlrb5hnz/0/2.m4s (19 live) GZIP 534ms 1237344 bytes (pipelined: 4)
after this we had error in playback reported by the Plex for Samrt TV App and playback position remained at 0
Jul 23, 2017 20:52:24.447 [2984] DEBUG - Request: [24.178.185.175:55736 (WAN)] GET /:/timeline?hasMDE=1&ratingKey=680&key=%2Flibrary%2Fmetadata%2F680&state=playing&playQueueItemID=11213&time=0&duration=672922 (13 live) GZIP Signed-in Token (Cdkrash)
Jul 23, 2017 20:52:24.462 [3968] DEBUG - Completed: [24.178.185.175:55736] 200 GET /:/timeline?hasMDE=1&ratingKey=680&key=%2Flibrary%2Fmetadata%2F680&state=playing&playQueueItemID=11213&time=0&duration=672922 (13 live) GZIP 13ms 759 bytes (pipelined: 25)
Jul 23, 2017 20:52:28.556 [4436] DEBUG - Request: [24.178.185.175:55736 (WAN)] GET /:/timeline?hasMDE=1&ratingKey=680&key=%2Flibrary%2Fmetadata%2F680&state=error&playQueueItemID=11213&time=0&duration=672922 (12 live) GZIP Signed-in Token (Cdkrash)
Jul 23, 2017 20:52:28.556 [4436] DEBUG - Client [e9yq9p0fydrl7gtomnxs5zic] reporting timeline state error, progress of 0/672922ms for guid=, ratingKey=680 url=, key=/library/metadata/680, containerKey=, metadataId=680
Jul 23, 2017 20:52:28.572 [3972] DEBUG - Completed: [24.178.185.175:55736] 200 GET /:/timeline?hasMDE=1&ratingKey=680&key=%2Flibrary%2Fmetadata%2F680&state=error&playQueueItemID=11213&time=0&duration=672922 (12 live) GZIP 11ms 760 bytes (pipelined: 26)
There should be some Plex for Smart TV debug logging option in the settings of the client to sent debug info to the server.
Does the sample Plex test GB 1-5-001.mkv play ok on the TV (Plex for Vizio (Vizio Sigma V1.5.6-UHD))?
