Your model has more 4.4.1 releases than the other older ones. AFAIK 4.4.x was released initially for newer models and came to the older models much later.
Yes the NAS responds - or it did. Model is TS-653A. About being able to ZIP the directory - I knew about the right click to ZIP contents but it kept failing… I would see a job start for the ZIP and then it would instantly fail. I tried numerous times. Then I tried copying it off the NAS but it is clear that wasn’t going to get me anywhere.
This morning I found that the NAS is no longer responding over GUI or SSH. It hangs trying to load login page for GUI and SSH gets me to the password but no further.
I think downgrading probably took an unstable situation and made it worse. I’m not really seeing any other way now but full factory reset. I don’t trust my data on this install anymore.
If you look at my previous replies, 4.4.1.1117 is working fine for me. OTOH, do you have pressing need to go to 4.4.1 ATM? I went to it before seeing the thread here; had I seen it I would have waited it out.
N.B. I was running the pulled 4.4.1 versions on my systems previously without much trouble. And I work on enterprise Storage systems professionally, so I tend to be more of an early adopter of new releases.
At minimum, I would look for a way to backup all data on my Plex install before trying 4.4.1, so that if the worst happens you can at least restore Plex back to it’s original state. I had been running Plex for months through various firmware upgrades in 4.3.x and 4.4.x and I got burned bad. I have all my media but I’m losing all my metadata so I have to setup Plex from scratch. In addition to the time I’m spending now completely re-configuring the NAS, I will have to spend about 2-3 days to get everything on Plex back the way I want it. This sucks. I’m enormously irritated.
EDIT - if anyone has a known good way to backup Plex in its current state when installed natively, can you please link/post here?
It tells you how to move an installation to a different system, a backup is just moving the install back into the same system. One big caveat is that PMS shouldn’t be running when you copy the files, so you’d need to script it using the stop and start functionality from the QPKG.
An automated backup would be phenomenal, onto an external drive or something. I’m no coder, and a mediocre scripter at best but I have some devops-type friends I could hit up… unless something is already built to do that?
If your installation is young enough that you can snapshot it, that might be the easiest way forward as long as keep in mind a snapshot is not a backup.
Regarding backing up the Plex data, I already have that code in hand.
I spent a lot of time making it as bullet-proof as possible and it does work.
The primary features:
Plex’s data is automatically saved when you uninstall the package. It moves all of it to the “PlexData” share which only admin can access in File Station.
When you reinstall, it retrieves that backup and puts it into position under .qpkg/PlexMediaServer. If you want to start fresh, you must remember to delete the backup copy from the “PlexData” share
Caveat:
If you have multiple volumes, when you uninstall PMS, there is a delay while your Plex data is saved to the primary CACHEDEV. Depending on the amount of data, this will take 2-3-4-5 minutes (same amount of time as “Migrate To”). Is this acceptable?
Other operating consideration
I can easily change the QNAP installation to have all Plex’s data live in the “PlexData” share. This is non-standard on QNAP. It also has the downside of making the “Migrate To” automated feature moot. Any move of data from HDD -> SDD (moving the share) must be performed manually by you (the admin) in FileStation.
If the PlexData share is on a volume which is snapshotted, then snapshots are inherent and immediately available to you.
Since this is one of the reasons I developed the code, what benefits, if any, would it have provided? What would the pitfalls have been ?
If you have more than the Linux default of 8192 directories (inclusive of subdirectories) in use, the table fills. The Linux kernel’s “iNotify” service can’t track any more without increasing the table size.
It’s fairly easy to do but does require a table update (unless I add something to the packaging to support it).
Can you find out how many directories are in use for your monitored media?
This is inclusive of all main and sub directories
That sounds like a good solution. In my use case, I don’t necessarily want to put PMS in a non-standard running state, with the live data in PlexData share. As written, your code would have potentially allowed me to backup my current metadata and settings so long as I had solid access to my volume - which was extremely flaky after the firmware upgrade. I had to have QNAP support assist even getting the volume accessible again, and had frequent freezes.
I suppose that my use case is best described as “if my NAS blows up, my PMS server + metadata survive”. So, if your code could back up PMS at regular scheduled intervals without having to manually uninstall/reinstall (just stop the server, backup, start the server) then this would help my use case. I could have a job in QTS copy this off to an external drive if there was a catastrophic event, which would make me feel better.
Have PMS always run in the “PlexData” share (just like it does on Synology) where the code is under vendor control but the data is under your control; free to backup using whatever automated backup utilities / tools you wish.
You make a good point with number 2 above. I hadn’t considered that other platforms use PlexData on the share and that was their standard. And it is entirely true that I could then backup the share using native QTS capabilities, so I’ll rescind my statement above. I think that would work for me. I have to rebuild QTS/Plex now from scratch, so when I get done I would greatly appreciate the code so I can test it out so I don’t have to do this again.