I may be suffering from a similar issue: I’ve just returned from a few days away, and the app on my LG TV is unable to connect to any of my Plex servers. I can access them from a laptop with no difficulties. Is there a fix for this? Let me know if logs etc. would be helpful.
Still doesn’t work on the QNAP nas. The wd is now working. What happened with plex that this has caused my QNAP to now not connect. It has been working so well for a long time?
Logs.zip (140.9 KB)
Plex.tv had a major failure.
The very next day, Let’s Encrypt, the certificate provider, failed.
Those two events, back to back, made a mess that the infrastructure team is working to make sure it both is more tolerant to such failures and can clean up automatically if it does.
As part of our investigating, would you please try something for me?
- Change the DNS provider IP address for the 192.168.0.3 address to point to Google (8.8.8.8 or 8.8.4.4) and restart PMS
then,
-
nslookup plex.direct(on the QNAP SSH command line)
- You should get an IPv4 address which is your WAN IP and one error (no IPv6).
- Please let me know if you get something other than that?
Getting the same error: “app.plex.tv is unable to connect to “xxxxx” securely”. I’m running PMS on a Mac, and cannot connect to it from any client in the house. Been like this for about 4 days now. Is the outage mentioned resolved?
Also this is really messed up to begin with… here I have a working server in my house, trying to access it within my own network, and yet I can’t because it is dependent on something external. What a bad implementation!
3 Likes
Ok. I’ll get the result but it will be Friday night because I’m on business travel and can’t get access to change the dns provider for the nas from my current location.
Update: configuring my LG TV’s internet settings manually, and overriding the DNS provider IP (previously the router, 192.168.1.1) to instead use the Google servers (8.8.8.8) resolves the problem for me, at least for now.
Checking my router settings, it is using DNS servers courtesy of my ISP: 208.76.152.1 and 208.76.152.9 . Is there any way to restore functionality with the original configuration?
I’m glad I just found this, I thought I had broken something on my setup and went to reinstalling everything…
Same symptom for me: if the DNS on the client machine is set to the router address, app.plex.tv fails to load, if I change it to something else existing out there (1.1.1.1 for instance), it works again. Good to have a workaround at least.
ChuckPa - it looks like when I followed your instructions to create a new share called PlexData to simply get logs, the entire database was moved to that location. I checked the normal reference location (via getcfg) and found that the database files in the .qpkg file location are much smaller than my backup files (library.db and library.blobs). So, when I cleaned that new share to do another run for logs it must have deleted the entire database. I do have a backup but I don’t know how to restore the backup to the right location and assure the files have the right permissions. If I restart the server to do the DNS test I don’t want it to further corrupt the database and potentially damage my backup files (not sure how that works).
Can you provide explicit instructions for recovery of the complete database from a scheduled backup? I know where the backup files are located and I think I know where the database should be stored, by the getcfg command. Can you also provide an understanding of what was actually done when I created that new “PlexData” share? The getcfg command did not return the new PlexData share location I created so it is very confusing. It returns the .qpkg location with much smaller db and blobs files than now stored in the backup location.
Lastly, what will happen if I do the DNS change, restart the server with a corrupted database?
ChuckPa, the more I’ve looked at this the more I’m concerned I don’t know what was done when I created the new share you requested. Also, it looks like the scheduled backup isn’t really a backup of the database but only some type of partial backup.
What actually happened when I created the PlexData share to get log files? Did the entire database get moved to that location, and only to that location? When I deleted the content of that new share to get only the latest log files, did that delete my entire database and library structure? And, if the scheduled backup isn’t really a backup of my plex database, does that mean I must rebuild the entire plex database structure, libraries, etc. manually?
Is the only way to create a true database backup to do a manual copy from the .qpkg location/folder via SSH to another location? Seems like there should be a much better way to have a complete database backup if this is all true.
I have no access to any content of the QNAP server at all now, so getting settings, library folder setup access to do a database rebuild is out of the question as well I guess - until the connection issues are fixed. It’s like plex isn’t even running on the QNAP now. Has progress been made to truly fix the plex errors that caused all this? I sure hope there is an easier answer than what I’m now thinking. I would appreciate some insights on all this since from what I’ve been reading, I completely misunderstood what was actually happening with the new PlexData share and that it was simply to get access to log files.
Thanks in advance.
Since I got no additional feedback I’ve done a combined database backup replacement using a much older full backup and the 3-day partial backup db files combined with a manual re-build. A lot of work frankly, but backup did save effort on about half the database. Looks like the PlexData share that was created is really a redirect to the .qpkg database location in the .qpkg folder. It is not independent and it does matter what is in that new share. It isn’t just to get logs. Probably good to be sure people know that when they create a new PlexData share with the simple intent to get access to logs.
I also found that the new instance of the server created during the rebuild on the same machine does finally show up via external access. But, it takes a long time to resolve the secure connection. Something significant has changed, and not for the better as it used to be instantaneous. It took hours to resolve even though using the LAN IP address/port to gain local access to setting when setting it up (instead of Plex.tv) showed that it was “fully accessible outside the network” instantly as before. Wonder why that would be the case… I shut down the plex.tv instance I was using and restarted it as a test - it took a long time to actually reconnect. It isn’t working like it did prior to the failure last week.
It is interesting to note that when a rebuild of the server database was executed, the Plex environment treated that as a completely new server instance. It did not recognize that it was the same intended server as the original even though it was on the same machine, used the same name, etc., and all related parameters listed in the authorized devices for that server were identical. Something else that probably could use improvement would be a simple check, or question, to confirm that it is the same intended server instance when all parameters are identical to another which already exists in the devices list - perhaps a suggestion for improvement.
Lastly, I did find in the forum confusing/conflicting statements that identified the newer PlexData share/folder method of database access to contain independent data and not directly related. That must certainly be incorrect since it is a redirect to the database storage location in the install directory. Hope others don’t make the same mistake of assuming the data are temporary and/or independent. I hope this helps others in the future.
-
The PlexData share method is hardly new. It was released in PMS 1.19.5 for all users. There were 2-3 months of preview / adjustments before & after initial launch. It is an optional method intended for those who do not possess / wish to use the SSH shell method.
-
Please see:
-
One thing which QNAP will permit, because it doesn’t know any better and I cannot prevent, is uninstalling PMS from one Volume and then reinstalling on a different volume. In these scenarios, you end up with a fully orphaned (previous) installation.
-
Installing applications on QTS is a ‘batch’ installation. The installation scripting has no way to provide constructive feedback. If I were to check and inform you you’re installing on the wrong volume, there is no means to get you that message.
-
If there is an orphaned installation on the NAS,
a. It can be found via SSH
b. It can be removed via SSH
I am working with QNAP to see if there is a way to add an interactive message mechanism to their QDK (developer’s kit)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
