Plex crashes after a while

Thanks for the GET /connections output and the logs. I spent a long time to work out when the lockout was. Please in future give an indication as to when an issue arises and also I should have asked for noting the time for when the the http://ip-of-pms:32400/connections is captured as that would be a clue as to what time to look at

what the logs show is that there was direct play playback to a Samsung TV UE55HU8200 and the samsung app was updating the server every second with the playback time position. All working ok - and then all of a sudden at 20:33:05 on Oct 30, requests started to take a long time to process and gaps in time appearing in the log. The timeline playback update that comes in every second from the samsung app normally completes in 20ms - but at 20:33:05 it took 34 seconds. After that requests just stacked up.

There was no other plex media server activity at the time - so it looks like may be an issue on the system you are running docker on. May be disk issues.

The crash reporting was triggered at 20:41:44 which I presume was when you did the kill -segv <pid>

The /connections list just shows about 10 stacked up timeline update requests and nothing else - so i do not believe this was a normal PMS deadlock - more like a system issue on the host machine.

The crash report reporting got stuck and did not actually upload a dmp file

Oct 30, 2018 20:42:09.549 [0x7f45e0d07780] DEBUG - HTTP requesting POST https://crashreport.plexapp.com

I do not know why that was and whether it was to do with the same system problem that affected the running of Plex Media Server or some other issue to do with your reverse proxy setup (an area that I cannot help with)

Could you look into system logs on the machine docker is running on to see if there were system issues at the time.

I will paste here extracts to show the gaps in time

This shows direct playing ok (the logged errors are normal) and every second the app reports playback state

Direct Play request completes ok
Oct 30, 2018 20:33:02.878 [0x7f3dfb3fe700] DEBUG - Auth: authenticated user 20501016 as Plex
Oct 30, 2018 20:33:02.878 [0x7f3decbfd700] DEBUG - Request: [10.10.10.58:54040 (Subnet)] GET /library/parts/128078/1519167647/file.mkv (8 live) Signed-in Token (Plex)
Oct 30, 2018 20:33:02.888 [0x7f3decbfd700] DEBUG - Content-Length of /data/tvshows/Frequency/Season 01/Frequency.S01E09.Das.Wandverlies.mkv is 5518316099.
Oct 30, 2018 20:33:03.074 [0x7f3dfbbff700] DEBUG - Failed to stream media, client probably disconnected after 2442776 bytes: 104 - Connection reset by peer
Oct 30, 2018 20:33:03.074 [0x7f3dfbbff700] DEBUG - Completed: [10.10.10.58:54040] 200 GET /library/parts/128078/1519167647/file.mkv (8 live) 196ms 2442776 bytes (pipelined: 1) (range: bytes=370861534-5518316098) 

Timeline update ok at 20:33:03 for playback at position 148.2 seconds
Oct 30, 2018 20:33:03.225 [0x7f3dfb3fe700] DEBUG - Auth: authenticated user 20501016 as Plex
Oct 30, 2018 20:33:03.231 [0x7f3ded3fe700] DEBUG - Request: [10.10.10.58:53930 (Subnet)] GET /:/timeline?type=video&state=playing&time=148200&duration=2408384&key=%2Flibrary%2Fmetadata%2F77219&ratingKey=77219&playQueueItemID=245097&playQueueID=5806 (7 live) GZIP Signed-in Token (Plex)
Oct 30, 2018 20:33:03.234 [0x7f3ded3fe700] DEBUG - Client [u7cnha5im4bns] reporting timeline state playing, progress of 148200/2408384ms for guid=, ratingKey=77219 url=, key=/library/metadata/77219, containerKey=, metadataId=77219, source=
Oct 30, 2018 20:33:03.238 [0x7f3ded3fe700] DEBUG - Play progress on 77219 'Das Wandverlies' - got played 148200 ms by account 20501016!
Oct 30, 2018 20:33:03.249 [0x7f3ded3fe700] DEBUG - [Now] User is Plex (ID: 20501016)
Oct 30, 2018 20:33:03.249 [0x7f3ded3fe700] DEBUG - [Now] Device is Samsung (TV UE55HU8200).
Oct 30, 2018 20:33:03.249 [0x7f3ded3fe700] DEBUG - [Now] Profile is Samsung
Oct 30, 2018 20:33:03.249 [0x7f3ded3fe700] DEBUG - [Now] Updated play state for /library/metadata/77219.
Oct 30, 2018 20:33:03.251 [0x7f3ded3fe700] DEBUG - Statistics: (u7cnha5im4bns) Reporting active playback in state 0 of type 4 (scrobble: 0) for account 20501016
Oct 30, 2018 20:33:03.254 [0x7f3dfbbff700] DEBUG - Completed: [10.10.10.58:53930] 200 GET /:/timeline?type=video&state=playing&time=148200&duration=2408384&key=%2Flibrary%2Fmetadata%2F77219&ratingKey=77219&playQueueItemID=245097&playQueueID=5806 (7 live) GZIP 23ms 565 bytes (pipelined: 101)

Direct Play request completes ok
Oct 30, 2018 20:33:03.680 [0x7f3dfb3fe700] DEBUG - Auth: authenticated user 20501016 as Plex
Oct 30, 2018 20:33:03.680 [0x7f3dec3fc700] DEBUG - Request: [10.10.10.58:54041 (Subnet)] GET /library/parts/128078/1519167647/file.mkv (8 live) Signed-in Token (Plex)
Oct 30, 2018 20:33:03.688 [0x7f3dec3fc700] DEBUG - Content-Length of /data/tvshows/Frequency/Season 01/Frequency.S01E09.Das.Wandverlies.mkv is 5518316099.
Oct 30, 2018 20:33:04.074 [0x7f3dfbbff700] DEBUG - Failed to stream media, client probably disconnected after 4837768 bytes: 104 - Connection reset by peer
Oct 30, 2018 20:33:04.074 [0x7f3dfbbff700] DEBUG - Completed: [10.10.10.58:54041] 200 GET /library/parts/128078/1519167647/file.mkv (8 live) 393ms 4,837,768 bytes (pipelined: 1) (range: bytes=372742486-5518316098) 

Timeline update ok at 20:33:04 for playback at position 149.2 seconds
Oct 30, 2018 20:33:04.238 [0x7f3dfb3fe700] DEBUG - Auth: authenticated user 20501016 as Plex
Oct 30, 2018 20:33:04.243 [0x7f3dedbff700] DEBUG - Request: [10.10.10.58:53930 (Subnet)] GET /:/timeline?type=video&state=playing&time=149200&duration=2408384&key=%2Flibrary%2Fmetadata%2F77219&ratingKey=77219&playQueueItemID=245097&playQueueID=5806 (7 live) GZIP Signed-in Token (Plex)
Oct 30, 2018 20:33:04.248 [0x7f3dedbff700] DEBUG - Client [u7cnha5im4bns] reporting timeline state playing, progress of 149200/2408384ms for guid=, ratingKey=77219 url=, key=/library/metadata/77219, containerKey=, metadataId=77219, source=
Oct 30, 2018 20:33:04.252 [0x7f3dedbff700] DEBUG - Play progress on 77219 'Das Wandverlies' - got played 149200 ms by account 20501016!
Oct 30, 2018 20:33:04.259 [0x7f3dedbff700] DEBUG - [Now] User is Plex (ID: 20501016)
Oct 30, 2018 20:33:04.259 [0x7f3dedbff700] DEBUG - [Now] Device is Samsung (TV UE55HU8200).
Oct 30, 2018 20:33:04.260 [0x7f3dedbff700] DEBUG - [Now] Profile is Samsung
Oct 30, 2018 20:33:04.260 [0x7f3dedbff700] DEBUG - [Now] Updated play state for /library/metadata/77219.
Oct 30, 2018 20:33:04.261 [0x7f3dedbff700] DEBUG - Statistics: (u7cnha5im4bns) Reporting active playback in state 0 of type 4 (scrobble: 0) for account 20501016
Oct 30, 2018 20:33:04.264 [0x7f3dfbbff700] DEBUG - Completed: [10.10.10.58:53930] 200 GET /:/timeline?type=video&state=playing&time=149200&duration=2408384&key=%2Flibrary%2Fmetadata%2F77219&ratingKey=77219&playQueueItemID=245097&playQueueID=5806 (7 live) GZIP 20ms 565 bytes (pipelined: 102)

Direct Play request completes ok
Oct 30, 2018 20:33:04.680 [0x7f3dfbbff700] DEBUG - Auth: authenticated user 20501016 as Plex
Oct 30, 2018 20:33:04.680 [0x7f3debbfb700] DEBUG - Request: [10.10.10.58:54042 (Subnet)] GET /library/parts/128078/1519167647/file.mkv (8 live) Signed-in Token (Plex)
Oct 30, 2018 20:33:04.691 [0x7f3debbfb700] DEBUG - Content-Length of /data/tvshows/Frequency/Season 01/Frequency.S01E09.Das.Wandverlies.mkv is 5518316099.
Oct 30, 2018 20:33:04.875 [0x7f3dfb3fe700] DEBUG - Failed to stream media, client probably disconnected after 1953352 bytes: 104 - Connection reset by peer
Oct 30, 2018 20:33:04.875 [0x7f3dfb3fe700] DEBUG - Completed: [10.10.10.58:54042] 200 GET /library/parts/128078/1519167647/file.mkv (8 live) 195ms 1953352 bytes (pipelined: 1) (range: bytes=376563758-5518316098) 

So all ok to 20:33:04.875

Then we get the pauses in time and also the drop out of the samsung tv

Timeline playback update at 20:33:05 for position 150.2 seconds
The processing of this request stalled and did not finish till much later

Oct 30, 2018 20:33:05.251 [0x7f3dfbbff700] DEBUG - Auth: authenticated user 20501016 as Plex
Oct 30, 2018 20:33:05.257 [0x7f3de8bff700] DEBUG - Request: [10.10.10.58:53930 (Subnet)] GET /:/timeline?type=video&state=playing&time=150200&duration=2408384&key=%2Flibrary%2Fmetadata%2F77219&ratingKey=77219&playQueueItemID=245097&playQueueID=5806 (7 live) GZIP Signed-in Token (Plex)
Oct 30, 2018 20:33:05.261 [0x7f3de8bff700] DEBUG - Client [u7cnha5im4bns] reporting timeline state playing, progress of 150200/2408384ms for guid=, ratingKey=77219 url=, key=/library/metadata/77219, containerKey=, metadataId=77219, source=

Direct Play request that hung
Oct 30, 2018 20:33:05.280 [0x7f3dfbbff700] DEBUG - Auth: authenticated user 20501016 as Plex
Oct 30, 2018 20:33:05.280 [0x7f3decbfd700] DEBUG - Request: [10.10.10.58:54043 (Subnet)] GET /library/parts/128078/1519167647/file.mkv (8 live) Signed-in Token (Plex)

Oct 30, 2018 20:33:05.298 [0x7f3de8bff700] DEBUG - Play progress on 77219 'Das Wandverlies' - got played 150200 ms by account 20501016!

Next set of timeline requests just stacked up
Oct 30, 2018 20:33:06.264 [0x7f3dfb3fe700] DEBUG - Auth: authenticated user 20501016 as Plex
Oct 30, 2018 20:33:07.277 [0x7f3dfbbff700] DEBUG - Auth: authenticated user 20501016 as Plex

Oct 30, 2018 20:33:08.722 [0x7f3de8bff700] DEBUG - [Now] User is Plex (ID: 20501016)
Oct 30, 2018 20:33:08.723 [0x7f3de8bff700] DEBUG - [Now] Device is Samsung (TV UE55HU8200).
Oct 30, 2018 20:33:08.723 [0x7f3de8bff700] DEBUG - [Now] Profile is Samsung
Oct 30, 2018 20:33:08.723 [0x7f3de8bff700] DEBUG - [Now] Updated play state for /library/metadata/77219.
Oct 30, 2018 20:33:08.724 [0x7f3decbfd700] DEBUG - Content-Length of /data/tvshows/Frequency/Season 01/Frequency.S01E09.Das.Wandverlies.mkv is 5518316099.
Oct 30, 2018 20:33:13.482 [0x7f3dfcbff700] DEBUG - [CompanionProxy] player 11a44novewlh5wa0oufeapdi was last refreshed 10 seconds ago

Oct 30, 2018 20:33:15.487 [0x7f3dfa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.990856 seconds: 10.10.10.58 ([TV]Samsung LED55)
Oct 30, 2018 20:33:15.487 [0x7f3dfa3ff700] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.990369 seconds: 10.10.10.254 (FRITZ!Box)
Oct 30, 2018 20:33:23.482 [0x7f3df73fd700] DEBUG - [CompanionProxy] player 11a44novewlh5wa0oufeapdi was last refreshed 20 seconds ago

So please first look into the system that the docker is running on to see if there were any disk issues/other system issues at the time and also may be some network issue - but that should not result in the gaps of time in the log

Ok, deadlocked while running procmon. PM’d link to you.

Thanks for the investigation.
But I can say that there is not any problem with the system the docker runs on. SInce my problems with Plex I use emby without any problem. I use emby since 4 weeks and I have never had any problem, network errors or something else. And as I already said I don’t use the reverse proxy with plex to minimize sources of error.
There are many other docker container running on the same machine and not any application has any error. The one and only is plex and it annoys me. All the problems came with the plex pass subscription.
Just now I stopped all containers but plex. Testing and the same error and absolutely nothing to see in /var/log/syslog or /var/log/messages. There is no problem on the host, it must be a plex related problem.

You sent me a dump - but that is no good without logs and if a deadlock without the connections list

Investigations start with just logs and if the logs show a deadlock then we can move into getting a dump and list of connections and logs

so first - ensure you are running with debug logging enabled on the server - see https://support.plex.tv/articles/201643703-reporting-issues-with-plex-media-server/

restart the server anyway - even if debug logging was already enabled - to get fresh logs created

When you get the problem, note down the time, restart the server and download the logs and attach the zip with info on what happened and when
See https://support.plex.tv/articles/200250417-plex-media-server-log-files/

I have been looking at the diagnostics provided over the past few days. It appears that we have an issue with handling repeated seeks when playing back and end up hitting timing issues within Plex Media Server that lead to the deadlock

Until the issue is looked into and fixed, tell your XBoxOne users not to go backwards and forwards and just playback the videos. If seeking is necessary, avoid multiple repeated actions too quickly

Thanks, I’ll make sure to let them know.

Any other suggestions regarding my problem?

I have PM’d you a link to the log files as per your request.

Thanks!

As an FYI, the drop was about 9:25PM Eastern Time on 11/10/18.

I do see that my server is set to send crash reports to Plex as well.

Thanks

I can see a shutdown at 21:15 whilst running 1.13.8.5395
A re;launch at 21:18 with version 1.13.9.5456
can’t see any crash. How did you notice the problem? What were you trying to access the server from ?

The logs show server running up to 21:29 when you downloaded the logs - which proves it was running as you accessed it to download the logs at 21:29

OK i can now see a deadlock started around 8:39 PM and continued until you shut down the server at 9:14 PM

I was looking for 9:25

Please could you follow the steps below for the diagnostics needed to investigate a deadlock. Hopefully straightforward

For deadlocks we need list of connections, process dump and logs. See below

For deadlocks we need process dump + list of connections + logs

Diagnostics for a deadlock / lockout (Windows)

  1. Prepare yourself by finding the server security token string as it will be needed for the connections list request. To find the token string, see this support article https://support.plex.tv/articles/204059436-finding-an-authentication-token-x-plex-token/
  2. When the problem occurs (and please wait for sufficient time before capturing diagnostics or restarting eg 10 minutes of requests to the server not getting through) , get the output from a specific browser request on the server. In a browser, go to this url http://localhost:32400/connections?X-Plex-Token=xxxxxxxxxxxxxxxxxxxxx where you put the server token string instead of the xxxxxxxxxxxxxxxx. Copy the displayed output to a text file and save and note down the exact time when the request response was returned
  3. Next is to force a process dump for the Plex Media Server.exe process. We can do this with Windows Task Manager - but on a 64-bit windows and with Plex Media Server.exe being a 32-bit application, you would need to load the 32-bit x86 version of windows task manager. So load this program instead of the default task manager C:\Windows\SysWow64\Taskmgr.exe
  4. Using this 32-bit Taskmgr.exe find the Plex Media Server.exe process, select it and right click on it and choose Create Dump
  5. Check that the dmp file has been created
  6. Restart the server and capture the zipped logs
  7. Zip the dmp files and upload to dropbox or similar service
  8. send me by private message link to the zipped dmp files and send the saved /connections output text files and the zipped logs

Thank you

Hi There,

Great, I will do this the next time I notice a deadlock.

Thanks so much!

Hello,

Deadlock happened around 7PM Eastern. I have pm’d you a OneDrive link with all the information you requested.

Thanks

Thank you very much. Good diagnostics. It has been referred to the development team. A timing issue to do with handling of seeks when transcoding

I’ve been getting this deadlock every couple of days and have been very frustrated. Sure enough, I found out this evening that one of my users was seeking on his Xbox One when it happened. I’m glad I found this thread.

Plex Media Server 1.14.0.5468 has just been released as Beta. It has a fix for the deadlock seen in diagnostics provided in this forum thread.

See Release Notice

  • (Transcoder) Resolved a rare deadlock (#9332)

Anyone running an early beta or a development build with early release of these fixes should now update to the official beta, Thank you for helping confirm the fixes

I would suggest updating to 1.14.0.5468 and then we look at new fresh diagnostics from that release - similar to what was provided before

Yep, no problems with the server over the last 2 days. Works great, thanks!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.