It’s an example - It’s not a forced location. The point of the script is it can be anywhere you want it to be, and you point the Task at that location. You don’t need to SSH or do anything else that might be overly technical for the admin, like you do in other update scripts.
None of this is hardcoded. It’s all based on where you save the script. If it doesn’t exist, then you can’t put the script there.
I’m not sure I follow the concern with the way the script is implemented. Whether User Homes are on or off, File Station should be able to access everything involved based on where the script is saved and executed from. Nothing is hard-coded so there is no blind assumption of paths that may or may not exist - it works based on its running environment. I’ve been testing this extensively, but if there is a scenario I have not considered I absolutely want to know about it and understand it. I don’t mean to sound argumentative (if I do). I’m not being defensive - I just don’t see your concern materializing with the way the script works. I’m far from perfect, so I appreciate the critique and caution.
Oh no worries, and I can understand the perceived ambiguity in the statement.
Thanks again for the concern and kind words. I appreciate you guys looking out for us 
When I am attempting to run this script manually via ssh it is just hanging:
Any idea what I am doing wrong?
Is what you see an indefinite hang, or does it take a really long time to return? There isn’t any error redirection in that version, so it’s not like any STDERR output is being hidden.
Unfortunately, I can’t imagine what the hangup is based on these screenshots alone. Which Synology and which version of DSM are you running?
If your system is up-to-date, I will edit a version of the script for you to run that will echo stages of the code as its running to help narrow down where you are getting stuck.
-
DS920+
-
DSM 6.2.3-25426 Update 2
It just hangs there and doesn’t return / continue and I eventually kill it.
That would be great if you could update the script.
Here’s a quick hack that should narrow things down:
The output will look similar to this if successful:
SYNO.PLEX UPDATER SCRIPT v2.3.3
* CHECKING FOR ROOT
* CHECKING DSM VERSION
* CHECKING HARDWARE INFO
* CHECKING SCRIPT LOCATION
* CHECKING PMS LOCATION
* DELETING OLD UPDATES
* GETTING PLEX TOKEN AND CHANNEL
* DOWNLOADING AND SCRAPING JSON
Synology: DS1019+ (x86_64), DSM 6.2.3-25426 Update 2
Script Dir: /volume1/homes/admin/scripts/bash/plex/syno.plexupdate
Plex Dir: /volume1/Plex/Library/Application Support/Plex Media Server
Plex Token: XXXXXXXXXXXXXXXXXXXX
Running Ver: 1.20.1.3252-a78fef9a9
Update Ver: 1.20.1.3252-a78fef9a9 (Public Channel)
Release Date: Thu, 27 Aug 2020 06:58:26 -0700Ok, thanks. So I figured out it was the fact that I am running a VPN. When I disconnect the VPN both scripts run normally. When the VPN is connected it just hangs.
Any idea?
Disregard. I had the service order wrong in my network interfaces. Thank you for doing this.
No worries. I’m glad you were able to make sense of it. I’m assuming the failure was with the curl download of the JSON data.
I’m sorry this happened to you, but I’m glad it did so that I can keep something like this in mind and/or compensate for it. I assumed the default timeout for curl would have tripped for this and would have thrown an appropriate connection error.
Perhaps there is something I can specifically do with the curl syntax to make certain that happens.
The next release version will have added checks for the flakey behavior of some apps and network connection time-outs (15 minutes until failure and the script continues). You can preview the all ~10 changes and test 
it if you’d like :
I’m calling this code commit v2.9.9. All functionality tweaks and fixes are done. Command-line option flags have not been added yet, but, now that everything else that I think needed to be addressed first is now done, I will be adding option flags before formally releasing the next major version of 3.0.0.
List of changes/fixes:
- changed ‘more’ scraping to ‘cat’ for stability
- changed old package-cleanup from “*.spk” to “PlexMediaServer*.spk”
- changed DSM version checking to be stricter
- added error checking at some application steps
- added timeouts for hung and problematic network connections
- changed error messages for clarity
- added details of update ‘new features’ and ‘fixed features’ if the update is successful
- changed /Updates location to script location for admin visibility and access
- added script self-check for version and create local version archive for easy roll-backs
- added /Archive folder for old package and script version storage
An update on v3.0.0:
The self-updating process is finished and I am satisfied with its stability. Here is an output example with the script modified to “think” its running a fake version 1.1.1:
SYNO.PLEX UPDATER SCRIPT v1.1.1
Script: syno.plexupdate.sh v1.1.1
Script Dir: /volume1/homes/admin/scripts/bash/plex/syno.plexupdate
Running Ver: 1.1.1
Online Ver: 2.3.3
Released: 2020-09-06 06:34:14-07:00 (16+ days old)
* Newer version found!
INSTALLING NEW SCRIPT:
----------------------------------------
2020-09-22 14:41:52 URL:https://raw.githubusercontent.com/michealespinola/syno.plexupdate/v2.3.3/syno.plexupdate.sh [6797/6797] -> "/volume1/homes/admin/scripts/bash/plex/syno.plexupdate/Archive/Scripts/syno.plexupdate.sh" [1]
----------------------------------------
* Script update succeeded!
In this example, the next time the script is run, it will be executing the new 2.3.3 code. Any additional error messages involving the update/overwrite (copy’s, move’s, and file comparison’s) would be shown within the dashed-line section.
Self-updating follows the same “safety” rule as with upgrading the PMS in that it will not update unless the new version is 7+ days old (default age setting).
Next version release for 3.0.0 is probably a week away. Here is an example of what the revamped script directory structure looks like:
| README.md
| syno.plexupdate.sh
\---Archive
+---Packages
| PlexMediaServer-1.20.1.3252-a78fef9a9-x86_64.spk
\---Scripts
syno.plexupdate.v1.1.1.sh
syno.plexupdate.v2.3.1.sh
syno.plexupdate.v2.3.2.sh
syno.plexupdate.v2.3.3.sh
syno.plexupdate.v2.9.9.sh
Note: The “Scripts” archive only contains copies of versions that you have run locally. It does not make an archive of versions listed on GitHub. For anyone (besides me) running this script, the first version you will have automatically archived in this folder will be at least v3.0.0 where this functionality is introduced.
Any archived script copies are unique to their filename as well as if they have been modified. If you modify your copy of the script, the archived copy will be overwritten to reflect that. This is not a store for “originals” (you can always get those off of GitHub). This is an archive for your running versions of the script.
Thank you so much for testing and catching that! While I think that I’ve since improved the logic to not let that happen, I’m going to go ahead and add ‘-p’ just in case 
I’ve updated that fix as well as posted the new self-update function in v.2.9.9.1:
You can enable self-updating by setting the variable ‘SelfUpdate=1’. It’s disabled by default.
Hi, now I found the thread for this too. 
Really great script! I initally only found the simple Plex update scripts, but since they have some issues (like hard-coded path to the Plex installation folder, PkgHasUpgrade bad input) started making some improvements, but luckily before I got too far found this, and it’s way better. 
So far I came across three things that might be worth considering:
-
How about instead of having the
Archivefolder in the same directory as the script, use something like/var/cache/syno.plexupdate. Perhaps the cache folder can be configurable. Then the location where the script is installed can be separated from where it’s cache is stored. -
For notifications using PkgHasUpgrade looks a bit weird, since it’ll say you can go to the Package Center and upgrade which isn’t the case. Instead perhaps it’s possible to make custom notifications for the script (see https://www.beatificabytes.be/send-custom-notifications-from-scripts-running-on-a-synology-new/). Unfortunately adding custom notifications does require a reboot of the NAS, the problem seems to be that a cache is generated in
/var/cache/textswhich is only updated on restart. I’ve been doing some digging but so far I haven’t been able to figure out how that cache can be regenerated without a restart.
-
The new features and bug fixes overview is really nice to have in the notifications, absolutely love it! Looking at the code though, it looks like it’s only displaying it for the version that was installed. So if you are running version 1 and you upgrade to version 3, you’re going to miss the release notes of version 2. Not sure if that’s something that can be solved in this script though. I’ve been trying to see if I can find some kind of overview of all the release notes for all versions, but except the Announcements thread in the forums I haven’t been able to so far. Though of course maybe I’m wrong and the version 2 release notes are shown in that use case, so do correct me if I’m wrong.
Thank you so much for the help testing and the kudos. I appreciate everything you guys do for Plex and the adjacent communities, and I’m thrilled to be able to give something back that is useful.
Please note I am not a developer. I’m an administrator and user, and that’s how I have approached writing this script. It also seemed like a great excuse to reacquaint myself with Bash
I’m absolutely open to new ideas and concepts to make the script more robust. I’ll try my best to address each point for consideration by also explaining why things currently are the way they are:
-
Initially, moving the
/Archivefolder (previously named “/Updates” and located in the PMS folder structure) into the script folder was to give non-technical Synology admins visibility and access to the downloaded packages without having to understand and use SSH-based tools. The goal was to make everything accomplishable within the common framework of the DSM, and to make updates and [re]installs easier with as much automation as possible.Originally, the
/Updatescache folder (now located at/Archive/Packages) was a continuation of the same concepts from other versions of “plexupdate” scripts that this script was originally based on. I now understand from various usage experiments and testing that keeping a cache of previously downloaded/installed packages is relatively useless because (AFAIK, someone please correct me if I am wrong) you can’t install an older version of a package over a newer version in DSM (no matter how hard I have tried). With that in mind, I’ve been considering removing the package cache unless I can determine a reason for keeping it.The Archive folder also stores previously run versions of the script (
/Archive/Scripts) for rollback purposes. Part of the reason I created this script cache was so it would be readily accessible to the admin if there are any problems with a newer version of the script and they need to go back to an older version. The cached version is updated (overwritten) with any customizations that the admin makes to the running core script. It is not intended to be a static copy of what is downloaded from GitHub. It’s an archive/backup of whatever the admin was running (including if it is renamed).All of the above-described folder changes and implementations have happened over weeks of revisions and testing while refining the script since its initial fork from the “martinorob/plexupdate” script. Eventually, I broke away from that source because what I had been [re]building had become wholly unique from the source material.
As far as I am aware, there is no way to access
/varfrom DSM’s File Station, etc, so moving the cache back into a location on the volume that is unreachable via DSM defeats part of the purpose of the script to “make it easier” for non-technical admins. But. I’m not apposed to making the location overridable via a variable and I think its a reasonable option to have. Submit a new request on GitHub and I will add it to the to-do list for a future version:https://github.com/michealespinola/syno.plexupdate/issues/new
-
Using
PkgHasUpgradeabsolutely looks weird and I dislike it immensely. But, its what the original forked script versions used - so I fixed some bits that were coded with broken syntax, and got as creative as I could with capturing better information from Task-based email notifications.I have experimented with a few other Synology/DSM tools for sending messages, and AFAIK
PkgHasUpgradeis the best thing we have that is built-in to the DSM and how it’s hooked into the internal notification system. The problem is that there is no generic message template, and we are forced into using a template that was designed for a different type of notification.I’ve probably spent the most time out of anything trying to come up with a better solution that ties into the DSM framework. At one point I did come up with some ways of customizing the message template system that
PkgHasUpgradeuses to not seem so hacky (using a new generic/open message template), but I put it off and essentially abandoned it because it was taking away way too much time from actually developing the functionality of the script. I eventually reached the conclusion that elegant notifications needed to be changed to a last step so I could move forward with getting functionality done.IIRC (its been a while), I think we are thinking of the same type of template modification as what is discussed on beatificabytes. Now thinking back to it again, part of the problem is that modifying the template requires using tools outside of my understanding of Bash and Synology’s Linux-based OS (have I mentioned that I’m a Windows guy?). The best examples I could find for simple config-file editing were in Perl. Python could do it but seemed to require more effort. I couldn’t figure out how to cleanly do it with Bash (awk, etc), and I was taking too much time trying to figure it out.
This is something I would still love to figure out a better solution for. But that will have to wait until I finish adding flag options to the code and release a stable and fully-functional 3.0.0 version. Priorities!
-
Yes, the new features and bug fix overview info is specific to and only shows information related to the update that was downloaded and installed. All update information is taken from JSON data in the official Plex update webpage. To the best of my knowledge and experimentation, the update information available only reflects the latest version. I do not believe I have a way to compare and calculate cumulative changes between versions. When you are selecting your application platform for Plex, you are not given a version selection outside of Public or Beta channel versions (Plex Pass off or on). You can only download the current version.
I hope this addresses your questions and sheds some light on why things are the way they currently are.
1 Like
-
Not using CLI/SSH is a very fair point. And I didn’t realize the
Archive/Scriptswas a backup rather than a cache. But from that perspective isn’t self-updating and doing custom changes contradictory to each other? Either you use the script as-is and allow it to use this wonderful self-update feature, then you don’t need to keep the scripts because previously versions can also be found on GitHub. Or you make custom changes to it but then you can’t use self-update because that would overwrite your changes and you’ll have to manually update (unless you want to incorporate some kind of patching mechanism, but that sounds really risky) and also manually arrange for your backups. So I don’t directly see the use case here for making a backup of a script itself. As for the SPK, I don’t have much experience with DSM yet on this level so I don’t know if / how downgrading is possible. -
Well it does use the built-in tools, but Injecting the custom notifications templates is indeed a little bit tricky. The more I think about it the more hesitant I become, because it does involve changing system files without an easy way to roll back those changes. Wouldn’t want to accidentally break other notifications. And either way, changing a system file that’s not accessible via File Station also doesn’t really work well with the no CLI/SSH idea.
-
@trumpy81 but the
MinimumAgeoption is actually explicitly meant to be able to skip a release if something went wrong. A quote from theREADME
The default yet modifiable settings are that the script will not install an update unless it is 7 days old. This is a stability safety-catch so that if a release has a bug, it is assumed it will be discovered and fixed within 7 days.
That’s what got me wondering about release notes for intermediate versions. But without any way of obtaining the release notes it’s unfortunately not easily done.
Regardless, I actually am a developer and very familiar with Bash. If there are things you’d like some help with let me know, I don’t mind getting my hands dirty on this. 
-
You also make fair points. Self-updating for the script is an option that is not and will not be enabled by default. I can’t account for everything and anything someone might do, so I’m swinging for the lowest common denominator here, and that’s the less technically inclined people that don’t understand SSH, etc. - and Bash script editing I think will probably be off the table for them as well.
One of the design points of the script is to not edit it. The functionality options are intended to be controlled by option flags that have not been added yet (they will be in v3.0.0). Now that all the core features are essentially dialed-in, adding the flags (likely utilizing
getops) is my next development step. v2.9.9.1 is essentially a beta pre-release of the next release version which contains significant changes from the previous release version.You would have to disable self-updating if you performed a manual roll-back or the update will just happen again, as there is currently no intelligence to understand that you have chosen to rollback. So there are a few technical quirks here that a more savvy user will have to manage to deal with for themselves. I’m assuming that if you customize the script, you’re already on a higher technical level and should be able to understand the consequences of your actions.
-
That’s another good point that led me to shy away from pursuing that notification strategy. I don’t want to break anything, and I don’t want to violate any TOS causing any conflict of interest between myself, Synology, and Plex. If I was to do another type of notification, I think it would ideally be between the
synonotifytool for in-DSM notifications and a 3rd-party emailer (likely ala python since I believe that it’s installed by default) for email notifications. I don’t like the idea of hacking Synology tools and config files, and I couldn’t come to an easy conclusion of anything that I could consider reliable as well as platform-available with DSM. There are still some older DSM versions that Plex can run on that I am trying to keep the script compatible with. -
The whole default 7-day waiting period as well as adding in the update descriptions was all my doing/concept. I don’t like the idea of installing brand-new updates (I got burned on a few bad beta channel updates, no offense @trumpy81
- but it really stems from being a Microsoft admin ), and I also wanted to provide as much detail about the update as possible since it otherwise seemed like an uninformative message simply stating that an update took place.
I’m open to all criticisms, suggestions, and any technical help I can get. Each feature that I’ve incorporated into the script has been a learning experience. I have tried to make the best choices in their implementation, but not being a developer, I’m completely dependant on outside critique to know if I’ve done things adequately or properly, and if I’ve leveraged the appropriate tools in the process.
Thinking about this some more, there might be something I can easily do. The script is already scraping the JSON about the update, so why not append that data to a flat log file? Search the log to see if it contains the scraped version #, if it doesn’t exist, append the file.
Or somewhat similarly, maybe have a new folder under /Archive to contain individual log files and create a new file named for each version encountered - containing the update info.
It’s not flawless or foolproof, depending on how often releases might come out within a 24-hour period, but it may be sufficient. Or maybe check for updates a little more often - like every 6 hours or something.
Either way, it should be pretty easy to implement. Everything except the file creation already exists.
I need coffee 
