Server Version#: PlexMediaServer-1.18.1.1973-0f4abfbcc-x86_64
I updated last night and since then, Plex is reachable only after restarting my Synology DS218+. Then after a few minutes, when accessing the web client, all of my libraries say that they’re unreachable. Same on the iOS app. Same using the Plex web app. This is happening inside and outside of my network.
I have been having the same issue on all the 1.18 versions i.e 1.18.0.1841, 1846, 1913, 1944, 1973. I am running the server on Windows 2012 R2 and it effects all clients i.e. local server, web clients, android, samsung tv, windows client etc. A stop and start of the Plex Server software fixes it for a while but then the issue comes back.
Similiar issue, for me it becomes unreachable after having played back a file for 5-10 minutes.
Usually becomes reachable again after 15-20 minutes.
Please get the logs and attach the ZIP it gives you.
We need DEBUG , not VERBOSE, to see what’s happening. Otherwise, it will continue to happen.
Attached.
Your logs contain all the VERBOSE information and are missing any of the events I’m looking for (VERBOSE logs too much data so we often miss what we’re waiting for)
mediaType=9&force=1&respectTags=1&parentGUID=com%2Eplexapp%2Eagents%2Enone%3A%2F%2F207402%3Flang%3Dxn&parentID=207402&guid=com%2Eplexapp%2Eagents%2Enone%3A%2F%2F207864%3Flang%3Dxn&id=207864
Nov 05, 2019 14:34:16.318 [0x7f4621037700] DEBUG - Request: [127.0.0.1:48108 (Loopback)] GET /system/agents/update?mediaType=9&force=1&respectTags=1&parentGUID=com%2Eplexapp%2Eagents%2Enone%3A%2F%2F207402%3Flang%3Dxn&parentID=207402&guid=com%2Eplexapp%2Eagents%2Enone%3A%2F%2F207864%3Flang%3Dxn&id=207864 (24 live) GZIP Signed-in
Nov 05, 2019 14:34:16.318 [0x7f4621037700] VERBOSE - * Host => 127.0.0.1:32400
Nov 05, 2019 14:34:16.318 [0x7f4621037700] VERBOSE - * User-Agent => Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36
Nov 05, 2019 14:34:16.318 [0x7f4621037700] VERBOSE - * Accept => */*
Nov 05, 2019 14:34:16.318 [0x7f4621037700] VERBOSE - * Accept-Encoding => gzip
Nov 05, 2019 14:34:16.318 [0x7f4621037700] VERBOSE - * mediaType => 9
Nov 05, 2019 14:34:16.318 [0x7f4621037700] VERBOSE - * force => 1
Nov 05, 2019 14:34:16.318 [0x7f4621037700] VERBOSE - * respectTags => 1
Nov 05, 2019 14:34:16.318 [0x7f4621037700] VERBOSE - * parentGUID => com.plexapp.agents.none://207402?lang=xn
Nov 05, 2019 14:34:16.318 [0x7f4621037700] VERBOSE - * parentID => 207402
Nov 05, 2019 14:34:16.319 [0x7f4621037700] VERBOSE - * guid => com.plexapp.agents.none://207864?lang=xn
Nov 05, 2019 14:34:16.319 [0x7f4621037700] VERBOSE - * id => 207864
Nov 05, 2019 14:34:16.319 [0x7f4621037700] DEBUG - [com.plexapp.system] Se
Having the same issue since upgrade, however mine runs well for a day or so, then becomes unreachable and requires a restart of Plex or NAS, then it works again, and this repeats in a day or so.
Please collect the logs as best you can (DEBUG on, VERBOSE off)
and post here.
I am closing your other thread as it is a duplicate.
I’d be happy to do this if my server was reachable. Last night, after your last response, I restarted my NAS. Still unreachable. This morning, not reachable. This afternoon, not reachable.
I’d also be happy to do this if the problem had some kind of pattern. It is not reproducible all the time.
you can manually collect the logs. (i structured PMS on Synology to allow this)
Control Panel - Shared Folders - EDIT the Plex share - Permissions - Give your username Permission to R/W
File Station -
Drill into the Plex share -> Library -----> until you see Logs(
Right click and Compress to Logs.zip
Download to your computer and then attach here please. It’s the exact same logs as PMS normally provides when download is requested.
Your logs are showing me the NAS is working overtime matching media.
Did you add a lot at once?
Do you have other services / app running?
The end result is the database can’t keep up .
From there , all of PMS degrades.
I see part of the problem.
Attempting to use software transcoding on a 32 bit Synology is going to bring it squarely to its knees.
Apr 16, 2016 11:46:54 [0xabb35b70] DEBUG - Job running: XDG_CACHE_HOME='/volume1/Plex/Library/Application Support/Plex Media Server/Cache/' XDG_DATA_HOME='/volume1/@appstore/Plex Media Server/Resources/' '/volume1/@appstore/Plex Media Server/Resources/Plex New Transcoder' '-i' '/volume1/homes/uhzyaj/TV Series/Supergirl/Season 01/Supergirl - 01x10.mkv' '-filter_complex' '[0:0]scale=w=min(1280\,iw):h=min(720\,ih):force_original_aspect_ratio=decrease[0]' '-map' '[0]' '-metadata:s:0' 'language=eng' '-codec:0' 'libx264' '-crf:0' '18' '-pix_fmt:0' 'yuv420p' '-maxrate:0' '3879k' '-bufsize:0' '7758k' '-preset:0' 'veryfast' '-x264opts:0' 'cabac=0:8x8dct=1:bframes=0:subme=0:me_range=4:rc_lookahead=10:me=dia:no_chroma_me:8x8dct=0:partitions=none' '-map' '0:1' '-codec:1' 'copy' '-copypriorss:1' '0' '-f' 'matroska' '-avoid_negative_ts' 'disabled' '-map_metadata' '-1' '-' '-start_at_zero' '-copyts' '-y' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-progressurl' 'http://127.0.0.1:32400/video/:/transcode/session/dwnypmljzrn5976mcmsyeewmi/progress'
Apr 16, 2016 11:46:54 [0x9a101b70] INFO - [Transcoder] Input #0, matroska,webm, from '/volume1/homes/uhzyaj/TV Series/Supergirl/Season 01/Supergirl - 01x10.mkv':
Metadata:
title : Supergirl S01E10 - RMTeam, Rapidmoviez.com
DESCRIPTION : Encoded By RMTeam, Rapidmoviez.com
ENCODER : Lavf56.40.101
Duration: 00:43:54.07, start: 0.000000, bitrate: 862 kb/s
Stream #0:0(eng), 3, 1/1000: Video: hevc (Main), yuv420p(tv), 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc
Metadata:
LANGUAGE : eng
ENCODER : Lavc56.60.100 libx265
DURATION : 00:43:54.069000000
Stream #0:1, 1, 1/1000: Audio: aac (LC), 48000 Hz, stereo, fltp (default)
Metadata:
ENCODER : Lavc56.60.100 aac
DURATION : 00:43:54.005000000
Apr 16, 2016 11:46:54 [0xabb35b70] DEBUG - [FFMPEG] Duration: 2634
Apr 16, 2016 11:46:54 [0xabb35b70] DEBUG - Read line, and done: 1
Apr 16, 2016 11:46:54 [0xabb35b70] DEBUG - Started session successfully: dwnypmljzrn5976mcmsyeewmi
Apr 16, 2016 11:46:54 [0xabe23b70] DEBUG - Started universal transcode output thread
Apr 16, 2016 11:46:54 [0xad3ffb70] DEBUG - [TranscodeOutputStream] Input processing thread started at offset 0 for -1 bytes.
Apr 16, 2016 11:46:54 [0xac3ffb70] INFO - [Transcoder] Output #0, matroska, to 'pipe:':
Metadata:
plex.duration : 2634.07
plex.total_duration: 2634.07
encoder : Lavf56.36.100
Stream #0:0(eng), 0, 1/1000: Video: h264 (libx264) (H264 / 0x34363248), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, max. 3879 kb/s, 23.98 fps, 1k tbn, 23.98 tbc
Metadata:
encoder : Lavc56.41.100 libx264
Stream #0:1, 0, 1/1000: Audio: aac ([255][0][0][0] / 0x00FF), 48000 Hz, stereo (default)
Apr 16, 2016 11:46:54 [0xad111b70] DEBUG - Request: [127.0.0.1:60863] PUT /video/:/transcode/session/dwnypmljzrn5976mcmsyeewmi/progress?width=1280&height=720 (19 live)
Apr 16, 2016 11:46:54 [0xad111b70] DEBUG - It took 0.0 sec to serialize a list with 0 elements.
Apr 16, 2016 11:46:54 [0xb1fffb70] DEBUG - Completed: [127.0.0.1:60863] PUT /video/:/transcode/ses
Respectfully, I suggest you confine yourself to H.264 video.
Additionally, in the logs you provided, I see it matching media. Is this correct? it’s still indexing new media?
That little Atom CPU is not very strong
Apr 14, 2016 20:54:41 [0xb2d11b70] INFO - Linux version: 3.2.40 (#5644 SMP PREEMPT Wed Oct 28 12:35:52 CST 2015)
Apr 14, 2016 20:54:41 [0xb2d11b70] INFO - Processor Intel(R) Atom(TM) CPU CE5335 @ 1.60GHz````Hi Chuck,
The issue happened again, the plex server became unreachable after about 29hours of being connected. Please see updated logs.Logs (08-11-2019).zip (9.3 MB)
Hi Chuck,
Thank you for your reply. I see, I’m not familiar with the technical stuff. What is the solution to my issue?
Regards,
Jeff
I’ve had the same issue, with a DS1518+ and a DS416Play. Both have large libraries (in fact duplicates) but I’ve never had issues before the recent versions of Plex. They can’t stay up for more than a couple of hours and I even when I restart Plex, it often does not show up in the client. Was hoping a new version of the beta would fix this but since it’s been a few weeks (been watching local sync copies since then), I thought I’d check in here. Will upload logs once I get Plex running long enough to do it. I’m considering switching back to GA / stable release if this doesn’t get fixed soon, makes the server nearly unusable.
Thanks for the logs but because you enabled VERBOSE logging, the information we were hoping to catch has fallen off the end of the log file buffer.
The buffer is only 5 files deep. Verbose logging writes about 10x more data than regular DEBUG.
DEBUG alone is more than sufficient for this plus it gives us a greater elapsed time window so we can see back before the fault occurred.
Would you mind doing the following?
Thanks.
Ok, I wasn’t aware of this, where can I find this setting to turn it off?
They are off by default. You can uncheck the box again by going to:
Settings - Server - General - Show Advanced
