Server Version#: Ubuntu 18.04.2 LTS
Player Version#: 1.15.5.994
My PMS server for the last few months has become very unstable. I haven’t updated the OS, just the PMS software. I cant seem to find anything in the logs that would point to why its crashing. PMS will stop working but the processes are still running. I have rebuilt the database, disabled the auto folder monitoring as it was stuck scanning on the odd day.
When I restart the PMS service it takes a few minutes to restart. which I find strange too, almost like there are some rogue processes going on that stop the service from stopping.
From what I can see on the boards, the plex team seems to fire fighting DVR atm. So until they get around to stabilising this product i’ve installed a copy of emby which is rock solid. I’ve also gone as far as to create a cron job to restart plex every night.
Also worth noting, emby seems faster and so far, has selected the correct meta data 100% of the time vs Plex which is doing wierd things.
I have looked at your crash from the 25th June and I would like to see more examples of crashes and corresponding logs - The last crash report I see is from 25th June. Any chance of trying again to repro the issue and let me have more debug server logs captured after a crash
Initially I just wanted to see more recent examples of the crashes but the june one was the last uploaded- so want to see logs after a crash to see if uploading is failing
No harm in adding verbose logging on top of debug logging, just whilst we are looking into the crashes - so do that please and also check crash reporting enabled
I noticed that mine crashed three times tonight back to back so I stopped the service, nuked the logs directory, then started it up again to get a clean set and here they are. From what I can tell it started with with .15 branch because if I fall back to the .14 I don’t hit this particular issue. Once this starts I haven’t found anything that seems to stop it even rebooting.
Plex: 1.16.1.1291-158e5b199
OS: CentOS 7.6.1810 all latest patches as of July 1
Here, PMS is just starting up, sees the crash dump and is starting to upload it .
There is still an active transcode waiting for data (which it starts to satisfy.
It can’t get to the DB because it thinks it’s locked
This feels like a corrupt database to me.
00294.ts (9 live) TLS 0ms 288 bytes (pipelined: 1) (range: bytes=634956-)
Jul 08, 2019 19:47:04.426 [0x7f415effd700] DEBUG - Job running: '/usr/lib/plexmediaserver/CrashUploader' '--directory=/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Crash Reports/1.16.1.1291-158e5b199' '--version=1.16.1.1291-158e5b199' '--platform=Linux' '--platformVersion=7 (Core)' '--serverUuid=17d3b7fc78dc5fc851e60e988d761dc981790949' '--userId=wilbur@wilpig.org' '--sentryUrl=https://sentry.io/api/1233455/minidump' '--sentryKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' '--vendor=CentOS Linux' '--model=x86_64' '--device=PC'
Jul 08, 2019 19:47:04.427 [0x7f415effd700] DEBUG - Jobs: Starting child process with pid 29983
Jul 08, 2019 19:47:04.487 [0x7f40ebfff700] ERROR - Failed to begin transaction (../Library/MetadataCollection.cpp:173) (tries=1): Cannot begin transaction. database is locked
Jul 08, 2019 19:47:04.488 [0x7f40eb7fe700] DEBUG - Library item 709247 'Revenge of the Rogues' got played by account 1837080!
Jul 08, 2019 19:47:04.490 [0x7f40eb7fe700] DEBUG - We're going to try to auto-select an audio stream for account 1837080.
This as foundation, there are two choices:
attempt to use a backup DB (if you still have them enabled - some folks turn them off)
Create a new test server instance (saving this one until a determination is made).
My database is quite large so setting up a blank test instance is just a non-starter. I’ve backed up the database and run a repair and will watch what happens. I’ve played the item that you listed there in the log as being locked at the time and it didn’t crash so hopefully that was it.
Just to add to what @ChuckPa said - the crash uploader log does not necessarily mean there was a new crash. If on launch Plex Media Server finds some old crash reports to upload, it will try again.
Crash reports uploading is rate limited and so not all crashes succeed in getting uploaded and a new attempt is made on relaunch.
You have cleared all the old logs and in the period covered by the new logs Jul 08, 2019 19:45:04 to Jul 08, 2019 19:47:21 there was no crash.
All there was is launch at 19:45:04 and then you shut it down a minute later 19:46:01.815 [0x7f52ca441700] DEBUG - Ordered to stop server.
and then relaunched at 19:46:04 and then shutdown a minute later 19:47:01.290 [0x7f3890bcd700] DEBUG - Ordered to stop server.
and then relaunched at 19:47:02 and logs collected
So no logs to cover a crash time
I do see uploaded crash reports - 3 from your server for these times
7th July 04:28 UTC
9th July 12:23 UTC
10th July 09:22 UTC
All to do with testing codecs. would need logs at time of crash to see what was happening
I have this problem - Plex processes all running but clients act like it isn’t. Happens once or twice a week.
Plex web client on :32400 is reachable but also can’t see the server (shows only others that I connect to).
I did post at greater length in a new thread before I saw this one.
Here are my logs at a point in time where this problem is visible. The server was working evening of the 17th up to about 2100+0200. When I looked now on the 18th about 1330+0200 it was broken.
Was the client remote / local / same subnet / different subnet?
Was it signed into the elbow plex.tv account - as per the server?
Was the problem on a specific browser ? eg Microsoft Edge ?
The logs were captured at 14:24 on Jul 18, 2019
Requests were coming through and processed from another local subnet 10.64.5.xx (server on 10.64.16.x subnet) up to just before the logs were captured - at 14:21
If that Plex Web session on IP 10.64.5.131 was not seeing the server then would need to see Plex Web verbose log for the time to go with server debug logs (for verbose web logging, it would be settings / web / show advanced / debug / enable verbose logging / save changes) and then when the problem arises, get the web log (settings / web / show advanced / debug / view log / select all and copy to text file) and get server logs zip
Being a different subnet, it would be treated as external and if it does not see the server on 10.64.16.2 - would then go through the remote access route
I do see some abnormalities in the server log with regards to remote access connectivity tests and I would like to see more recent logs and also with current public or beta version of Plex Media Server
Turns out that the other Plex media server - the old one on my QNAP NAS - was using the same uuid of what have you so they were stepping on one another.
The testing 10.64.16 is my home and 10.64.5 is my office network. There is a dedicated link with no NAT.
