With the release of QTS 4.3.5 I guess the feature set is locked, so now the question is, when will the Plex support it?
One of the things optimized is te QSync, which should use less CPU, which should leave some more muscle for Plex 
It’s going to be a bit.
QTS 4.3.5 unexpectedly went public release early.
PMS is known to have problems with 4.3.5 Beta 3.
As I attempted to use 4.3.5.0713 release, my development system became unusable forcing me to revert to 4.3.4.
Please allow us time to work with QNAP and sort out the issues.
Hi Chuck.
THANKYOU! For being up front about this, and taking the time to make it work properly, no need to rush it for my sake, for me, the WAF factor has great impact, so it would be nice for it to be very stable.
Any updates on this? Safe to proceed to 4.3.5 yet?
It seems to be, I updated mine a few days ago. Fixed the problems I had with Virtualization Station (it didn’t find it for some reason), and fixed Plex which didn’t start at first, oddly, after I had started it from the command line, it has started as it should after the next reboot (and firmware update).
Very interesting things they have implemented with SSD over-provisioning, so it now helps you set this, to get a better sustained performance from the SSD, and keep the SSD alive for a longer time.
I’m sorry, Somehow I didn’t get notified of this thread.
QTS has had a few updates for most of us… This helped a lot and seems to have taken care of most of the issues.
No changes to PMS have yet been required other than minor adjustments to the new ARMv8 beta.
This was expected and the Beta releases are near complete (meaning full production is next). PMS is definitely quicker.
The ARMv8 issue appears to impact one model. There is no logic to this as of yet. I was alerted yesterday and spent these past two days on it.
Sounds exciting!
Hmmm, maybe I’ve got some other problem going on as I still can’t get anything newer than 1.13.4 to work with my QNAP (4.3.5 releases, have never knowingly run beta firmware. Currently on 4.3.5.0760 with a TS-471)
Most recently I tried 1.14.0.5465 and was not able to connect to the NAS, even when going directly to the IP address. (Not just app.plex.tv)
1.13.4 seems to work, and I still have the installer but it worries me that there’s something borked in my configuration if everybody else has gotten past this problem.
Checking now. I am updated to 4.3.5.0760
I did the install of 1.14.0.5465 without issue.
DId you reboot QTS after the firmware upgrade?
Yes - and just did again to be sure. Same issue (or at least, same symptom.)
copy out the URL and do a command line curl of it to a file.
Remember, it’s a SHAR file (shell archive) sometimes browsers mess it up.
Right-click “Save As” is the easiest option.
curl -o filename.qpkg URL is the other
Sorry to be dense - what do you mean by “it” in this context? The Plex URL? Why a .qpkg file then?
(After last reboot and a long wait, it IS working with the direct IP address, but not from app.plex.tv or any devices)
May I see the logs? Plex/Web not working from app.plex.tv means there is something else going on.
The question here pertains to QTS and Plex? QTS applications are .qpkg extensions.
That’s what I figured - wasn’t sure how you’d reference a QTS application from a URL (but am not that familiar with their underlying structure.)
Here’s the 1.14 log Plex Media Server.log (1.0 MB)
I do need more than just 1 log file. To make it worse, you have VERBOSE mode turned on. This means I don’t know what else was lost in the other log files.
Since you found the location (are you using PMSlibshare ?) a ZIP of the entire Logs directory is best for me to start with.
Also, DEBUG mode is the only thing we need. VERBOSE causes too much data to be lost. VERBOSE mode limits us to about 2 minutes of activity. Normal DEBUG can capture an entire day.
Please recreate as best you can after turning off VERBOSE.
OK sorry about that - haven’t messed with this in the past.
I just ssh’d in from another box.
I reloaded 1.13.4, changed logging to debug only, then rebooted the NAS, then reloaded 1.14, then attempted to load from IPaddress:32400/web, then zipped up the whole Logs directory.
Hope this helps, and really do appreciate you being on these forums and helping. I’m pretty sure if I nuked everything and started over I could get the latest running but last time I did that I spent forever recreating the database.
JYLogs.zip (2.6 MB)
Your logs show me it is playing.
Nov 18, 2018 00:00:30.136 [0x7fe1c6fff700] DEBUG - Auth: authenticated user 1 as dulinor
Nov 18, 2018 00:00:30.136 [0x7fe1b9c47700] DEBUG - Request: [192.168.0.103:50227 (Subnet)] GET /:/timeline?ratingKey=34041&key=%2Flibrary%2Fmetadata%2F34041&playbackTime=559&playQueueItemID=12675&state=buffering&hasMDE=1&time=3031000&duration=6473000 (27 live) TLS GZIP Signed-in Token (dulinor)
Nov 18, 2018 00:00:30.137 [0x7fe1b9c47700] DEBUG - Client [pe4lrcl6ohdvkc8j3d0zkmrc] reporting timeline state buffering, progress of 3031000/6473000ms for guid=, ratingKey=34041 url=, key=/library/metadata/34041, containerKey=, metadataId=34041, source=
Nov 18, 2018 00:00:30.184 [0x7fe1b9c47700] DEBUG - Play progress on 34041 'Sing' - got played 3031000 ms by account 1!
Nov 18, 2018 00:00:30.184 [0x7fe1b9c47700] DEBUG - [Now] User is dulinor (ID: 1)
Nov 18, 2018 00:00:30.184 [0x7fe1b9c47700] DEBUG - [Now] Device is Chrome (Chrome).
Nov 18, 2018 00:00:30.184 [0x7fe1b9c47700] DEBUG - [Now] Profile is Web
Nov 18, 2018 00:00:30.184 [0x7fe1b9c47700] DEBUG - [Now] Updated play state for /library/metadata/34041.
What is the specific problem please?
Well, the problem WAS that I couldn’t connect to the QNAP server from the web interface (or from various apps.) This particular cycle seems to have restored access, which I can’t explain.
Could easily be idiot human error, or something around the config changes to debug. Sorry for wasting your time!
