I’m honestly not sure if I’m posting this properly since this is the first major issue I’ve ever had with Plex in all the years I have used it. I’m getting a connection refused error after the server runs for a few days on my QNAP TS-251+ I am running the latest QNAP firmware and was running the latest Plex until this issue happened. It will work again if I stop it from the App Center or Restart the NAS entirely but it crashes shortly after doing so within a day… I have UPnP active and have tried nearly everything I have fund in the forums without success. I am at my wits end but still hopeful someone can give me insight to fix it.
There is something which is causing a super hard crash.
By this I mean that The log file ends with a bunch of null characters.
The only time I have seen this in the past is when the OS failed or the OS force terminated something because of process corruption. It looks as if PMS is about to write to the log and the log record itself is corrupted deep within the library. The problem comes because text strings are always terminated with a single null character. To see a string of nulls is extremely unusual.
This is going to be extremely difficult to find
What has changed recently on the host? Firmware? PMS? Something else ?
I’ve truncated the bottom of the log but these are the last few lines. I truncated all the nulls down to something more reasonable
Oct 19, 2019 07:36:14.846 [0x7fb43442a700] DEBUG - Completed: [127.0.0.1:32996] 200 GET /livetv/sessions/486ce621-8977-4248-866e-89d4877567de/7476bd80-aafc-40fa-af38-151125d30a54/02016.ts (6 live) 2ms 942444 bytes (pipelined: 1010)
Oct 19, 2019 07:36:14.846 [0x7fb43442a700] DEBUG - Removed transcode data consumer, active count 1 => 0
Oct 19, 2019 07:36:14.945 [0x7fb3dee6b700] DEBUG - Transcoder segment range: 0 - 2171 (2171)
Oct 19, 2019 07:36:15.162 [0x7fb3b3d11700] DEBUG - HTTP requesting GET http://192.168.1.2:80/discover.json
Oct 19, 2019 07:36:15.164 [0x7fb3b3d11700] DEBUG - HTTP 200 response from GET http://192.168.1.2:80/discover.json
Oct 19, 2019 07:36:15.164 [0x7fb3b3d11700] DEBUG - HTTP requesting GET http://192.168.1.2:80/lineup_status.json
Oct 19, 2019 07:36:15.176 [0x7fb3b3d11700] DEBUG - HTTP 200 response from GET http://192.168.1.2:80/lineup_status.json
Oct 19, 2019 07:36:15.713 [0x7fb3dcb43700] DEBUG - Request: [127.0.0.1:33012 (Loopback)] GET /livetv/sessions/486ce621-8977-4248-866e-89d4877567de/7476bd80-aafc-40fa-af38-151125d30a54/02017.ts (6 live) Signed-in
Oct 19, 2019 07:36:15.714 [0x7fb3dcb43700] DEBUG - Content-Length of /share/CACHEDEV2_DATA/.qpkg/PlexMediaServer/Library/Plex Media Server/Cache/Transcode/Sessions/plex-transcode-486ce621-8977-4248-866e-89d4877567de/media-02017.ts is 977788.
Oct 19, 2019 07:36:15.717 [0x7fb43442a700] DEBUG - Completed: [127.0.0.1:33012] 200 GET /livetv/sessions/486ce621-8977-4248-866e-89d4877567de/7476bd80-aafc-40fa-af38-151125d30a54/02017.ts (6 live) 3ms 977788 bytes (pipelined: 1008)
Oct 19, 2019 07:36:15.717 [0x7fb43442a700] DEBUG - Removed transcode data consumer, active count 1 => 0
Oct 19, 2019 07:36:15.906 [0x7fb3df447700] DEBUG - Transcoder segment range: 0 - 2172 (2172)
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\0
I was having so much trouble with the current version that I literally wiped the NAS and resetup the drives. and installed whatever the version in QNAP App store was 1.16.3 I think. It is still running right now but I have no idea for how long. It apparently still records even in the crash state but comes up as Unreachabke from the web interface or the QNAP Dashboard. It has been doing it ever since possible 1.17 ish or perhaps the last Firmware update I’m running QTS 4.4.1 build 1081 now
So I have a TS-451+, and it runs well on 4.3.6-1070. After the situation where they pulled 1040 and 1050 off the download page, I swore I wouldn’t upgrade to 4.4.x until the third stable patch. I’m treating this like Windows NT.
You said you’re running QTS 4.4.1-1081 on a TS-251+ https://www.qnap.com/en/download?model=ts-251%2B&category=firmware
According to the download page, your firmware has been revoked.
iirc they were offering that version to me as stable for about a week.
Now it’s just betas.
According to the list of NAS models supported by the 4.4.1-stable that’s out there,
you and I pretty much have the only models not on the list.
My conclusion is that 4.4.1 isn’t an option for the two of us, and it’s unproven for the rest.
I have faith. Do you think that downgrading is going to be a reasonable option?
I’m the kind of person who would start over from scratch.
That’s a lot of reset button tactics and rebuilding the NAS like you just unboxed it.
Gives you a chance to blow out the dust. ChuckPA may have other ideas & tips.
He’s very involved with QNAP.
I suppose it’s possible to install 4.3.6 over 4.4.1 and it will downgrade it.
Would be a better topic in their forums maybe?
I was going to mention this forum article before. You need to login to see the post, but it’s the official QNAP English forum where we’ve been talking about this firmware and the newer one. It’s been a bumpy road for a few people.
I’ve had no problems with any PMS version on my NAS. I think I started with 1.15.
It runs remarkably well, thanks to ChuckPA and everyone else involved.
Well maybe not perfectly with a VPN, but that’s likely my bad.
I’m on 1.18.1 the current beta now. What’s nice about this version in particular is how much better the logs are, and how well it investigated and cleaned itself up during install.
Ok, I went back to 4.3.6 by installing overtop of 4.4.1. I had to uninstall the codec pack and reinstall the earlier version but everything else is working with 1.18.1 so far we will see if it makes it more than a day I hope. Thank you for the help I’ll post back with my status after a day or two to let you know how it went.
