Plex Media Server keeps Crashing

Plex Media Server Desktops & Laptops
61

@Smokindog said:

@sa2000 said:
As I have not seen this exact issue anywhere else and I have seen many lockouts, could you see if you have installed some software recently that may be interfering with the tcp ip / ssl connections that Plex is doing. eg some vpn software / proxy / network bandwidth control and management - just in case

I am running PLEX “native” on a W10 Pro machine, i7-4470, 8Gb, Intel wireless AC. It locks up the network stack quite regularly. I’m on the beta release to “solve” the DVR issue and it’s really unstable. When the server locks up as seen by live TV hanging on a client, I can not remote in to the host machine until the PLEX server rights itself and/or I have to go to the host and reboot it.

so a transient lockout ?

until the PLEX server rights itself

Which beta are you on?

If there is a lockout - I need to see logs with debug logging enabled and then decide if we need to get deadlock diagnostics

62

@sa2000 said:

@Smokindog said:

@sa2000 said:
As I have not seen this exact issue anywhere else and I have seen many lockouts, could you see if you have installed some software recently that may be interfering with the tcp ip / ssl connections that Plex is doing. eg some vpn software / proxy / network bandwidth control and management - just in case

I am running PLEX “native” on a W10 Pro machine, i7-4470, 8Gb, Intel wireless AC. It locks up the network stack quite regularly. I’m on the beta release to “solve” the DVR issue and it’s really unstable. When the server locks up as seen by live TV hanging on a client, I can not remote in to the host machine until the PLEX server rights itself and/or I have to go to the host and reboot it.

so a transient lockout ?

until the PLEX server rights itself

Which beta are you on?

If there is a lockout - I need to see logs with debug logging enabled and then decide if we need to get deadlock diagnostics

Version 1.12.3.4973
Can’t get to the logs as the PLEX server is down, the IP stack is locked up, and there is no access to the machine.

Do you guys even have test machines set up in normal use? I mean just like a home user would have set up for live TV. These things happen so frequently I can’t believe they don’t happen in your lab, if you have a QA lab that is.

I volunteered to do testing in exchange for a free PLEX Pass for life but was declined. I paid for a lifetime after getting stuck for a monthly after the free trial. So in essence I paid MORE than the normal cost of the lifetime (monthly was pro-rated). Again, I think the product has hope but don’t ask people to pay for something AND be your only source of QA.

If I can get the logs next time it happens I will but usually I have to walk upstairs to the host machine and I just forget to do it.

PS - add a button to the GUI to send you what ever logs and information you need. Make this button visible only to users who volunteer to test for you. Have the process generate an ID code that can be included in the user report so you can cross reference the data to the report. this also eliminates any angst of data from your server being posted on public blogs.

That’s what other companies do to make it as easy as possible to get free testing from paying customers. Just a bit of free marketing advice.

63

If the windows tcp ip stack is locking up, it is unlikely to be a Plex issue and could be drivers / firmware or add on networking product

The only similar issue I have come across was on windows server 2012 and windows server 2008 fixed by Microsoft in the R2 releases

64

@sa2000 said:
If the windows tcp ip stack is locking up, it is unlikely to be a Plex issue and could be drivers / firmware or add on networking product

The only similar issue I have come across was on windows server 2012 and windows server 2008 fixed by Microsoft in the R2 releases

I guess anything is possible but this problem is always associated with a PLEX client losing connection, clears up when PMS is restarted, never happens if PMS is disabled, and wasn’t an issue before installing PLEX. I guess it could all be coincidence but I don’t believe those!

65

Just a heads up had 4 crashes today, 1 of them was 5 mins after the previous one as well!

66

@bradolson83 said:
Just a heads up had 4 crashes today, 1 of them was 5 mins after the previous one as well!

I have about 6-8 per day…

67

@Smokindog said:

@bradolson83 said:
Just a heads up had 4 crashes today, 1 of them was 5 mins after the previous one as well!

I have about 6-8 per day…

I started looking at the logs you provided. Initial thoughts - it looks like the network is ceasing for a period of time eg between 12 and 13 (not near the logs at the moment - so cannot give exact times)

Do check power saving options on the network card and PC

68

@sa2000 said:

@Smokindog said:

@bradolson83 said:
Just a heads up had 4 crashes today, 1 of them was 5 mins after the previous one as well!

I have about 6-8 per day…

I started looking at the logs you provided. Initial thoughts - it looks like the network is ceasing for a period of time eg between 12 and 13 (not near the logs at the moment - so cannot give exact times)

Do check power saving options on the network card and PC

Again, all that has been checked out. If I disable PLEX PMS, my NAS and other home automation services provided by this server work flawlessly. This IMO is a PLEX triggered issue. I spend a lot of my time collecting all this information and really do not appreciate the continue response of “it’s not a PLEX issue” that I see for so many of the reported bugs across these threads.

Thanks again.

69

@Smokindog said:

@sa2000 said:
As I have not seen this exact issue anywhere else and I have seen many lockouts, could you see if you have installed some software recently that may be interfering with the tcp ip / ssl connections that Plex is doing. eg some vpn software / proxy / network bandwidth control and management - just in case

I am running PLEX “native” on a W10 Pro machine, i7-4470, 8Gb, Intel wireless AC. It locks up the network stack quite regularly. I’m on the beta release to “solve” the DVR issue and it’s really unstable. When the server locks up as seen by live TV hanging on a client, I can not remote in to the host machine until the PLEX server rights itself and/or I have to go to the host and reboot it.

@Smokindog said:

@sa2000 said:
If the windows tcp ip stack is locking up, it is unlikely to be a Plex issue and could be drivers / firmware or add on networking product

The only similar issue I have come across was on windows server 2012 and windows server 2008 fixed by Microsoft in the R2 releases

I guess anything is possible but this problem is always associated with a PLEX client losing connection, clears up when PMS is restarted, never happens if PMS is disabled, and wasn’t an issue before installing PLEX. I guess it could all be coincidence but I don’t believe those!

@Smokindog said:

@sa2000 said:

@Smokindog said:

@bradolson83 said:
Just a heads up had 4 crashes today, 1 of them was 5 mins after the previous one as well!

I have about 6-8 per day…

I started looking at the logs you provided. Initial thoughts - it looks like the network is ceasing for a period of time eg between 12 and 13 (not near the logs at the moment - so cannot give exact times)

Do check power saving options on the network card and PC

Again, all that has been checked out. If I disable PLEX PMS, my NAS and other home automation services provided by this server work flawlessly. This IMO is a PLEX triggered issue. I spend a lot of my time collecting all this information and really do not appreciate the continue response of “it’s not a PLEX issue” that I see for so many of the reported bugs across these threads.

Thanks again.

I am afraid I cannot see any evidence of a Plex problem. There is no build up of any requests and there is no evidence of any hanging requests

I do hear what you say that the issues arise when Plex is running - but that does not necessarily mean the problems are in Plex

If you switch on an electric light and the whole electric circuit goes down, it does not necessarily mean it is the light bulb that is at fault.

I know you say you have checked everything but the evidence points to some network related issues.

when the TV could not find the server at 13:02, was the server accessible directly in a browser on http://127.0.0.1:32400/web ?

I can see you got in with Google chrome at 13:07.

Could you look at the Windows System Event Log through Eventvwr.exe selecting Windows Logs and then System and see what was logged between 12:02 and 13:07 on April 25

I notice that the connections to the pubsub servers are failing - is internet blocked / partially blocked?
They are used for determining there is an internet connectivity and also for confirmation of availability of remote access. The pubsub servers - appear as linode servers when looking up the IP

Apr 25, 2018 12:20:49.450 [9356] DEBUG - EventSource: Failure in IdleTimeout (0 - The operation completed successfully).
Apr 25, 2018 12:20:49.451 [9356] ERROR - EventSource: Retrying in 15 seconds.

Apr 25, 2018 12:21:04.451 [9356] DEBUG - EventSource: Resolving 45.79.11.43 port 443s
Apr 25, 2018 12:21:04.452 [9356] DEBUG - EventSource: Resolved 45.79.11.43 to 45.79.11.43
Apr 25, 2018 12:21:05.094 [9356] DEBUG - EventSource: Connected in 630 ms.
Apr 25, 2018 12:21:05.095 [9352] DEBUG - EventSource: Wrote data, reading reply.
Apr 25, 2018 12:21:06.053 [9352] DEBUG - EventSource: Read HTTP reply header.
Apr 25, 2018 12:21:06.054 [9352] DEBUG - EventSource: Successfully connected to 45.79.11.43.

Also notice longish connection times close to the time when you had issues

Apr 25, 2018 12:59:23.471 [9356] DEBUG - EventSource: Connected in 2401 ms.
Apr 25, 2018 12:59:53.500 [9356] DEBUG - EventSource: Connected in 3160 ms.
Apr 25, 2018 13:00:43.233 [9352] DEBUG - EventSource: Connected in 1368 ms.

Normally they are below 500ms

Apr 25, 2018 11:30:06.564 [9356] DEBUG - EventSource: Connected in 242 ms.
Apr 25, 2018 11:30:28.386 [9352] DEBUG - EventSource: Connected in 260 ms.
Apr 25, 2018 11:32:14.162 [9352] DEBUG - EventSource: Connected in 226 ms.
Apr 25, 2018 11:33:34.429 [9352] DEBUG - EventSource: Connected in 72 ms.

There was a network issue / dropout of devices several times - this is one example

Apr 25, 2018 12:01:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.584991 seconds: 192.168.110.4
Apr 25, 2018 12:01:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.825161 seconds: 192.168.110.5
Apr 25, 2018 12:01:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.808148 seconds: 192.168.110.21
Apr 25, 2018 12:01:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.692065 seconds: 192.168.110.22
Apr 25, 2018 12:01:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.695068 seconds: 192.168.110.23
Apr 25, 2018 12:01:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.837169 seconds: 192.168.110.25
Apr 25, 2018 12:01:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.650036 seconds: 192.168.110.31
Apr 25, 2018 12:01:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.331726 seconds: 192.168.110.32

and more examples

Apr 25, 2018 12:02:59.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.342905 seconds: 192.168.110.31
Apr 25, 2018 12:02:59.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.173004 seconds: 192.168.110.33
Apr 25, 2018 12:03:00.805 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.31 (http://192.168.110.31:8060/)
Apr 25, 2018 12:03:02.001 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.33 (http://192.168.110.33:8060/)
Apr 25, 2018 12:03:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.432902 seconds: 192.168.110.4
Apr 25, 2018 12:03:29.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.720368 seconds: 192.168.110.5
Apr 25, 2018 12:03:29.747 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.636733 seconds: 192.168.110.21
Apr 25, 2018 12:03:29.747 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.780400 seconds: 192.168.110.25
Apr 25, 2018 12:03:29.747 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.465220 seconds: 192.168.110.30
Apr 25, 2018 12:03:33.360 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.25 (http://192.168.110.25:8044/rootdesc.xml)
Apr 25, 2018 12:03:37.879 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.5 (http://192.168.110.5:8773/desc1.xml)
Apr 25, 2018 12:03:37.948 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.21 (http://192.168.110.21:8768/rootdesc.xml)
Apr 25, 2018 12:03:38.056 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.4 (http://192.168.110.4:49152/xmldoc/InternetGatewayDevice.xml)
Apr 25, 2018 12:03:39.745 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.256143 seconds: 192.168.110.22
Apr 25, 2018 12:03:39.745 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.284396 seconds: 192.168.110.23
Apr 25, 2018 12:03:39.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.112097 seconds: 192.168.110.32
Apr 25, 2018 12:03:39.774 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.32 (http://192.168.110.32:8060/)
Apr 25, 2018 12:03:40.681 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.30 (http://192.168.110.30:8060/)
Apr 25, 2018 12:03:57.973 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.23 (http://192.168.110.23:8779/rootdesc.xml)
Apr 25, 2018 12:03:57.975 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.22 (http://192.168.110.22:8363/rootdesc.xml)
Apr 25, 2018 12:04:49.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.713776 seconds: 192.168.110.22
Apr 25, 2018 12:04:49.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.715785 seconds: 192.168.110.23
Apr 25, 2018 12:04:50.769 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.22 (http://192.168.110.22:8363/rootdesc.xml)
Apr 25, 2018 12:04:50.770 [11308] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.110.23 (http://192.168.110.23:8779/rootdesc.xml)
Apr 25, 2018 12:05:09.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.585196 seconds: 192.168.110.4
Apr 25, 2018 12:05:09.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.760292 seconds: 192.168.110.21
Apr 25, 2018 12:05:09.746 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.826765 seconds: 192.168.110.25
Apr 25, 2018 12:05:09.747 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 21.686805 seconds: 192.168.110.32
Apr 25, 2018 12:05:09.747 [11308] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 20.260855 seconds: 192.168.110.33

You could look at network packets with wireshark to see what happens when the network goes down and what was going on before that

I can see evidence of having multiple routers on the network -

Apr 25, 2018 13:01:02.961 [13432] DEBUG - PublicAddressManager: got WAN IP 192.168.1.5 from router
Apr 25, 2018 13:01:02.962 [13432] WARN - PublicAddressManager: WAN IP is a private IP address

Apr 25, 2018 13:01:16.950 [2008] DEBUG - PublicAddressManager: got WAN IP 192.168.1.5 from router
Apr 25, 2018 13:01:16.950 [2008] WARN - PublicAddressManager: WAN IP is a private IP address

Apr 25, 2018 13:07:26.238 [7316] DEBUG - PublicAddressManager: got WAN IP 192.168.1.5 from router
Apr 25, 2018 13:07:26.239 [7316] WARN - PublicAddressManager: WAN IP is a private IP address

My advice would be to look into the network

Also try wired Ethernet for the server instead of wifi and eliminate one of the routers to simplify the setup and see if you can isolate the problem area

70

Sorry but your analysis is terrible and flawed. You do NOT see multiple routers on the PMS network. 192.168.1.5 is the WAN IP of the router I use as my private network gateway. 192.168.1.1 is the Frontier Router. My PMS network is 192.168.110.X.

I don’t really have time to collect all the information you request and then read your flawed responses to deny bugs in PLEX. I’m now VERY sorry I purchased a lifetime Plex Pass recently. I’ve worked on and managed very large software projects over the past 40 years. I usually would fire people who always contorted situations to deny there was a problem with their software.

If you are a principal with PLEX then the software is in grave danger.

Have a nice evening.

71

@Smokindog said:
Sorry but your analysis is terrible and flawed. You do NOT see multiple routers on the PMS network. 192.168.1.5 is the WAN IP of the router I use as my private network gateway. 192.168.1.1 is the Frontier Router. My PMS network is 192.168.110.X.

When there is a public IP (47.1xx.xxx.xxx) and WAN IP detected from the router which is in the private range (192.168.1.5) and a local network subnet of 192.168.110.xx, that suggests there is double NAT / multiple routing.

It was an observation I made based on what I saw in the logs

I don’t really have time to collect all the information you request

It was suggestions to help identify the problem.

72

So i ended up creating a linux box for plex and it has been running for the last week with no crashes at all! Everything is running seamlessly! So not a priority but given i can get it working with the same setup just on linux shows it would have to be a software issue?

73

@bradolson83 said:
So i ended up creating a linux box for plex and it has been running for the last week with no crashes at all! Everything is running seamlessly! So not a priority but given i can get it working with the same setup just on linux shows it would have to be a software issue?

Thanks for the feedback.

I am still surprised no one else had the deadlock type that your windows system had.

74

@sa2000 said:

@Smokindog said:
Sorry but your analysis is terrible and flawed. You do NOT see multiple routers on the PMS network. 192.168.1.5 is the WAN IP of the router I use as my private network gateway. 192.168.1.1 is the Frontier Router. My PMS network is 192.168.110.X.

When there is a public IP (47.1xx.xxx.xxx) and WAN IP detected from the router which is in the private range (192.168.1.5) and a local network subnet of 192.168.110.xx, that suggests there is double NAT / multiple routing.

It was an observation I made based on what I saw in the logs

I don’t really have time to collect all the information you request

It was suggestions to help identify the problem.

It is double NAT but it is NOT double routing on the local network. That’s why I say your analysis is flawed. This is all local access on the 192.168.110.X network. What happens on the other side of that router is irrelevant and noise, an attempt to deflect the fact that PLEX is the problem.

75

@Smokindog said:

@sa2000 said:

@Smokindog said:
Sorry but your analysis is terrible and flawed. You do NOT see multiple routers on the PMS network. 192.168.1.5 is the WAN IP of the router I use as my private network gateway. 192.168.1.1 is the Frontier Router. My PMS network is 192.168.110.X.

When there is a public IP (47.1xx.xxx.xxx) and WAN IP detected from the router which is in the private range (192.168.1.5) and a local network subnet of 192.168.110.xx, that suggests there is double NAT / multiple routing.

It was an observation I made based on what I saw in the logs

I don’t really have time to collect all the information you request

It was suggestions to help identify the problem.

It is double NAT but it is NOT double routing on the local network. That’s why I say your analysis is flawed. This is all local access on the 192.168.110.X network. What happens on the other side of that router is irrelevant and noise, an attempt to deflect the fact that PLEX is the problem.

You are right in that the Double NAT configuration might not be a factor but it does show that this is not a normal network configuration

The only way to establish if Plex Media Server is bringing the whole network down by doing something illegal / incorrect behaviour, is to have a network sniffer and may be starting with wireshark to look at the network traffic leading up to the network going down. Also the windows system and application event logs may have some clues

76

Again, you are just flat out wrong in every way on this. The only double NAT is access from outside the network and there is NONE in any of this discussion… PLEX IS the problem here and you need to resolve it. Plex is locking up the network interface on the host machine.

@sa2000 said:

@Smokindog said:

@sa2000 said:

@Smokindog said:
Sorry but your analysis is terrible and flawed. You do NOT see multiple routers on the PMS network. 192.168.1.5 is the WAN IP of the router I use as my private network gateway. 192.168.1.1 is the Frontier Router. My PMS network is 192.168.110.X.

When there is a public IP (47.1xx.xxx.xxx) and WAN IP detected from the router which is in the private range (192.168.1.5) and a local network subnet of 192.168.110.xx, that suggests there is double NAT / multiple routing.

It was an observation I made based on what I saw in the logs

I don’t really have time to collect all the information you request

It was suggestions to help identify the problem.

It is double NAT but it is NOT double routing on the local network. That’s why I say your analysis is flawed. This is all local access on the 192.168.110.X network. What happens on the other side of that router is irrelevant and noise, an attempt to deflect the fact that PLEX is the problem.

You are right in that the Double NAT configuration might not be a factor but it does show that this is not a normal network configuration

The only way to establish if Plex Media Server is bringing the whole network down by doing something illegal / incorrect behaviour, is to have a network sniffer and may be starting with wireshark to look at the network traffic leading up to the network going down. Also the windows system and application event logs may have some clues

77

@Smokindog said:
Again, you are just flat out wrong in every way on this. The only double NAT is access from outside the network and there is NONE in any of this discussion… PLEX IS the problem here and you need to resolve it. Plex is locking up the network interface on the host machine.

@sa2000 said:

@Smokindog said:

@sa2000 said:

@Smokindog said:
Sorry but your analysis is terrible and flawed. You do NOT see multiple routers on the PMS network. 192.168.1.5 is the WAN IP of the router I use as my private network gateway. 192.168.1.1 is the Frontier Router. My PMS network is 192.168.110.X.

When there is a public IP (47.1xx.xxx.xxx) and WAN IP detected from the router which is in the private range (192.168.1.5) and a local network subnet of 192.168.110.xx, that suggests there is double NAT / multiple routing.

It was an observation I made based on what I saw in the logs

I don’t really have time to collect all the information you request

It was suggestions to help identify the problem.

It is double NAT but it is NOT double routing on the local network. That’s why I say your analysis is flawed. This is all local access on the 192.168.110.X network. What happens on the other side of that router is irrelevant and noise, an attempt to deflect the fact that PLEX is the problem.

You are right in that the Double NAT configuration might not be a factor but it does show that this is not a normal network configuration

The only way to establish if Plex Media Server is bringing the whole network down by doing something illegal / incorrect behaviour, is to have a network sniffer and may be starting with wireshark to look at the network traffic leading up to the network going down. Also the windows system and application event logs may have some clues

I just want to have proof through wireshark capture that we are doing something out of the ordinary on the network.

I am discussing it with the development team

78

@Smokindog said:
Again, you are just flat out wrong in every way on this. The only double NAT is access from outside the network and there is NONE in any of this discussion… PLEX IS the problem here and you need to resolve it. Plex is locking up the network interface on the host machine.

@sa2000 said:

@Smokindog said:

@sa2000 said:

@Smokindog said:
Sorry but your analysis is terrible and flawed. You do NOT see multiple routers on the PMS network. 192.168.1.5 is the WAN IP of the router I use as my private network gateway. 192.168.1.1 is the Frontier Router. My PMS network is 192.168.110.X.

When there is a public IP (47.1xx.xxx.xxx) and WAN IP detected from the router which is in the private range (192.168.1.5) and a local network subnet of 192.168.110.xx, that suggests there is double NAT / multiple routing.

It was an observation I made based on what I saw in the logs

I don’t really have time to collect all the information you request

It was suggestions to help identify the problem.

It is double NAT but it is NOT double routing on the local network. That’s why I say your analysis is flawed. This is all local access on the 192.168.110.X network. What happens on the other side of that router is irrelevant and noise, an attempt to deflect the fact that PLEX is the problem.

You are right in that the Double NAT configuration might not be a factor but it does show that this is not a normal network configuration

The only way to establish if Plex Media Server is bringing the whole network down by doing something illegal / incorrect behaviour, is to have a network sniffer and may be starting with wireshark to look at the network traffic leading up to the network going down. Also the windows system and application event logs may have some clues

Have been concentrating on network activity and there was nothing in the log to suggest any excessive network activity round the time - 13:02.

But there is evidence of a lot of processing with back-to-back activities running - so may be it was just CPU intensive for a while

Does the problem only arise after watching livetv for a long period?
Do you have multiple livetv sessions ? what plex client ? and if more than one session - would they be separate browser windows or same browser window but separate tabs?

When it happens - would killing the live tv sessions recover the server?

79

I have sent you a PM with development build 1.13.4.5217 to update to. Changes were made to address this deadlock.

80

Plex Media Server version 1.13.4.5251 has just been released as beta. It has fixes for two deadlocks following investigations from diagnostics provided in this forum thread

See Release Notice Plex Media Server

  • (Playback) Rare deadlock with stopping sessions (#8659)
  • (Streaming Brain) Rare deadlock involving bandwidth limits (#8498)