I can confirm that downgrading to Version 1.9.2.4285 fixed the problem fro me.
so something in the beta is wrong…
I can confirm that downgrading to Version 1.9.2.4285 fixed the problem fro me.
so something in the beta is wrong…
Yip. Same here.
@sa2000
I see a lot of people saying the new version is unstable,
example;
forums.plex.tv/discussion/291740/pms-1-9-5-4339-46276db8d-not-working-after-update#latest
i think you need to check again whats going on.
Maybe try different database logs?
from another user?
im having major issue with every update. constantly crashing as well since 1.9.5.xxxx. i have downgraded to Version 1.9.3.4290 and everything is fine so far.
@bolagnaise said:
im having major issue with every update. constantly crashing as well since 1.9.5.xxxx. i have downgraded to Version 1.9.3.4290 and everything is fine so far.
There is nothing i can do without logs and if it is crashing, to have crash reporting not disabled.
I cannot see any crash reports for your server
If it is a lockout, then a couple were addressed in beta release 1.9.6.4401
http://forums.plex.tv/discussion/comment/1549008/#Comment_1549008
For logs
see
https://support.plex.tv/hc/en-us/articles/201643703-Reporting-issues-with-Plex-Media-Server
https://support.plex.tv/hc/en-us/articles/200250417-Plex-Media-Server-Log-Files
Just a note to say that I am still having this issue on 1.9.7.4441. Again, only on one of my Plex servers that is running Windows Home Server 2011 (Windows Server 2008 R2). Windows 10 is fine (1709). I’ve enabled debug logging and will provide logs when it occurs again.
@sa2000 … I thought this issue had gone away after upgrading to 1.9.7.4460. But over the past couple of nights, PMS (running on Windows Home Server 2011) has become unresponsive once again. Basically trying to access the web page produces a 503 error. Exiting PMS via the tray icon does not shut down all the processes. I have to manually kill them all via Task Manager before I can launch PMS again. Both times it was between 7pm and 8pm (7:58pm last night and 7:19pm tonight). Yesterday, it corrected itself around an hour later (9:02pm). Today, it did not. Attached are the logs. These are post killing all the services and relaunching PMS this evening.
Thanks.
Ran into this issue as well a couple of weeks ago. The only solution I found was to roll back to Version 1.9.6.4401. That seems. To have fixed the issue for now.
@DamnedOne said:
@sa2000 … I thought this issue had gone away after upgrading to 1.9.7.4460. But over the past couple of nights, PMS (running on Windows Home Server 2011) has become unresponsive once again. Basically trying to access the web page produces a 503 error. Exiting PMS via the tray icon does not shut down all the processes. I have to manually kill them all via Task Manager before I can launch PMS again. Both times it was between 7pm and 8pm (7:58pm last night and 7:19pm tonight). Yesterday, it corrected itself around an hour later (9:02pm). Today, it did not. Attached are the logs. These are post killing all the services and relaunching PMS this evening.Thanks.
A number of deadlock issues have been addressed and fixed. It appears that there is still one more. I do not know if this specific one has been addressed already post 1.9.7.4460 - the only way to identify causes for deadlocks is through a Process Dump and together with the logs and the info of active /connections
The logs show the problem started just after 19:17:09 on 24 November
So please do the following at the next occurrence
- capture the information on active connections. You can do that in a browser on the server itself using
127.0.0.1or from a local PC specifying the local IP of the server.
For doing it on the server, it would be http://127.0.0.1:32400/connections?X-Plex-Token=xxxxxxxxxxxxxxxxxxx
See this article for how to find out the server security token
https://support.plex.tv/hc/en-us/articles/204059436-Finding-an-authentication-token-X-Plex-Token
Save the output to a text file
Next is to dump the Plex Media Server.exe process
This can be done using Windows Task Manager or SysInternal Process Explorer - see Process Explorer - Sysinternals | Microsoft Learn
We have variety of outcomes with some users getting good dump out of Task Manager and others not so but needed Process Explorer. The resulting dmp file should be zipped and uploaded to dropbox or similar service and you can send me a link to it together with the /connections output text file,
Next is to restart the server and capture the logs. You can either attach here or put them with the uploaded dmp file
@sa2000 said:
@DamnedOne said:
@sa2000 … I thought this issue had gone away after upgrading to 1.9.7.4460. But over the past couple of nights, PMS (running on Windows Home Server 2011) has become unresponsive once again. Basically trying to access the web page produces a 503 error. Exiting PMS via the tray icon does not shut down all the processes. I have to manually kill them all via Task Manager before I can launch PMS again. Both times it was between 7pm and 8pm (7:58pm last night and 7:19pm tonight). Yesterday, it corrected itself around an hour later (9:02pm). Today, it did not. Attached are the logs. These are post killing all the services and relaunching PMS this evening.Thanks.
A number of deadlock issues have been addressed and fixed. It appears that there is still one more. I do not know if this specific one has been addressed already post 1.9.7.4460 - the only way to identify causes for deadlocks is through a Process Dump and together with the logs and the info of active
/connectionsThe logs show the problem started just after 19:17:09 on 24 November
So please do the following at the next occurrence
- capture the information on active connections. You can do that in a browser on the server itself using
127.0.0.1or from a local PC specifying the local IP of the server.For doing it on the server, it would be
http://127.0.0.1:32400/connections?X-Plex-Token=xxxxxxxxxxxxxxxxxxx
See this article for how to find out the server security token
https://support.plex.tv/hc/en-us/articles/204059436-Finding-an-authentication-token-X-Plex-Token
Save the output to a text fileNext is to dump the Plex Media Server.exe process
This can be done using Windows Task Manager or SysInternal Process Explorer - see Process Explorer - Sysinternals | Microsoft Learn
We have variety of outcomes with some users getting good dump out of Task Manager and others not so but needed Process Explorer. The resulting dmp file should be zipped and uploaded to dropbox or similar service and you can send me a link to it together with the/connectionsoutput text file,Next is to restart the server and capture the logs. You can either attach here or put them with the uploaded dmp file
Thanks for the reply. I will gather the info up when the issue occurs again and come back to you.
@sa2000 I have messaged you with a link to the PMS DMP. I had also just upgraded to 1.10.0.4523 earlier in the day. PMS became unavailable at 11:36pm on 29 Nov. I was unable to grab the requested connections information as the web interface was not available.
Thanks.
@DamnedOne said:
@sa2000 I have messaged you with a link to the PMS DMP. I had also just upgraded to 1.10.0.4523 earlier in the day. PMS became unavailable at 11:36pm on 29 Nov. I was unable to grab the requested connections information as the web interface was not available.Thanks.
Thank you very much for getting the diagnostics.
For some reason the dump does not show any useful stack frames for the threads within the process. This does happen sometimes and I do not know why. What I normally do is change the method of getting the process dump
Eg if the corrupt dump was acquired with Windows Task Manager, then switch to SysInternals Process Explorer instead. and vice versa if the other way round
So we need to capture another set of diagnostics to try and get usable process dump
An observation and I am not aware that it has anything to do with deadlocks. I have noticed that Plex Media Server process is using Per Session Temporary Directory - this has been seen to give rise to issues before eg loading the dashboard and the use of such temp file occurs when using Terminal Server or RDP to launch Plex Media Server. It may also be the default on windows server platforms, See the \1 directory in the path for Temp
TEMP=C:\Users\ADMINI~1\AppData\Local\Temp\1
TMP=C:\Users\ADMINI~1\AppData\Local\Temp\1
You could try and avoid that to see if it has a bearing on the issue. I would not expect it to
@sa2000 said:
@DamnedOne said:
@sa2000 I have messaged you with a link to the PMS DMP. I had also just upgraded to 1.10.0.4523 earlier in the day. PMS became unavailable at 11:36pm on 29 Nov. I was unable to grab the requested connections information as the web interface was not available.Thanks.
Thank you very much for getting the diagnostics.
For some reason the dump does not show any useful stack frames for the threads within the process. This does happen sometimes and I do not know why. What I normally do is change the method of getting the process dump
Eg if the corrupt dump was acquired with Windows Task Manager, then switch to SysInternals Process Explorer instead. and vice versa if the other way roundSo we need to capture another set of diagnostics to try and get usable process dump
An observation and I am not aware that it has anything to do with deadlocks. I have noticed that Plex Media Server process is using
Per Session Temporary Directory- this has been seen to give rise to issues before eg loading the dashboard and the use of such temp file occurs when using Terminal Server or RDP to launch Plex Media Server. It may also be the default on windows server platforms, See the\1directory in the path for TempTEMP=C:\Users\ADMINI~1\AppData\Local\Temp\1 TMP=C:\Users\ADMINI~1\AppData\Local\Temp\1You could try and avoid that to see if it has a bearing on the issue. I would not expect it to
Thanks for the info. I have the server auto logging in on boot and PMS starting on Windows Startup. This should start it as the console session (ID0). I do manage it via RDP, but I do use the console session (/admin) switch. I’ll double check though. I did grab that DMP with Task Manager. I’ll switch to Process Explorer and grab it again.
Is it a windows server platform ? The default I believe was changed by Microsoft to enforce per session temp directory for server platforms
@sa2000 said:
Is it a windows server platform ? The default I believe was changed by Microsoft to enforce per session temp directory for server platforms
Yes it is. WHS 2011 (aka Server 2008 R2). I rebooted the box and it no longer has the 1 suffix for the temp folder. So, I assume I must have connected at some stage to the other admin session and started PMS from the wrong one.
@DamnedOne Hi - I now know why the process dump was corrupt. Apparently on a windows 64-bit system you cannot use the system’s Windows Task Manager to dump a 32-bit program process.
There is actually a hidden 32-bit windows task manager that can be used and it can be loaded manually from C:\Windows\SysWow64\Taskmgr.exe !
It is explained here https://blogs.msdn.microsoft.com/tess/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine/
Another option is to use Process Explorer as i mentioned or also SysInternals Procdump.exe which is here https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
Parameters for dumping the process in command line window:
procdump.exe -ma <pid>
where <pid> is the process number for Plex Media Server.exe
@DamnedOne said:
@sa2000 said:
Is it a windows server platform ? The default I believe was changed by Microsoft to enforce per session temp directory for server platformsYes it is. WHS 2011 (aka Server 2008 R2). I rebooted the box and it no longer has the 1 suffix for the temp folder. So, I assume I must have connected at some stage to the other admin session and started PMS from the wrong one.
Some good news. The cause of these lockouts has now been identified and a fix is being written
Plex Media Server beta release 1.12.0.4829 has just been released
It has fixes for lockouts relating to photos library scanning
See Release Note
- (Photos) Re-scanning a photo section which had a significant amount of files renamed could lead to database lockups (#7653)
