fatalfurry Posted June 23, 2017 Share Posted June 23, 2017 I'm getting the following error using 6.4.0-rc5 when viewing the auto update settings. Fatal error: Cannot redeclare mk_option() (previously declared in /usr/local/emhttp/plugins/dynamix/include/Helpers.php:117) in /usr/local/emhttp/plugins/dynamix.plugin.manager/include/PluginHelpers.php on line 57 Quote Link to comment
Ashe Posted June 23, 2017 Share Posted June 23, 2017 4 minutes ago, fatalfurry said: I'm getting the following error using 6.4.0-rc5 when viewing the auto update settings. Fatal error: Cannot redeclare mk_option() (previously declared in /usr/local/emhttp/plugins/dynamix/include/Helpers.php:117) in /usr/local/emhttp/plugins/dynamix.plugin.manager/include/PluginHelpers.php on line 57 same here on two systems Quote Link to comment
Squid Posted June 23, 2017 Author Share Posted June 23, 2017 15 minutes ago, fatalfurry said: I'm getting the following error using 6.4.0-rc5 when viewing the auto update settings. My post immediately before yours 11 minutes ago, Ashe said: same here on two systems My post 2 before yours The actual script should still run. (But If you need to change the settings for a particular reason, let me know and I'll help you modify the settings by hand.) 1 Quote Link to comment
jrdnlc Posted July 7, 2017 Share Posted July 7, 2017 Is this a bug? Jul 6 18:00:09 unRAID Plugin Auto Update: ca.docker.autostart.plg version 2017.07.06 does not meet age requirements to updateJul 6 18:00:10 unRAID Plugin Auto Update: enhanced.log.plg version 2017.07.06 does not meet age requirements to updateJul 6 18:00:11 unRAID Plugin Auto Update: preclear.disk.plg version 2017.07.05c does not meet age requirements to update I'm on 6.3.5 Quote Link to comment
Squid Posted July 7, 2017 Author Share Posted July 7, 2017 It's July 6, the update was released July 6, and you probably have the settings to not install updates unless they are at least 3 days old. Quote Link to comment
LSL1337 Posted September 4, 2017 Share Posted September 4, 2017 Hi guys, not sure if this is the right place to ask, but is it possible to manually set automatic restart time for certain dockers? For example the official plex docker (used by a lot of people) doesn't support this auto-update function. the docker is always updated to the latest version when it is _manually_ restarted. is it possible to set a fixed time, for the X docker be restarted every day or every week, or when the other app is updated? maybe this extra fucntion could be added to the plug-in? it would be useful for a lot of users Quote Link to comment
Squid Posted September 4, 2017 Author Share Posted September 4, 2017 3 hours ago, LSL1337 said: is it possible to set a fixed time, for the X docker be restarted every day or every week Use the user scripts plugin The script will be docker stop -t 60 Plex docker start Plex Set up a custom cron time to run it (or choose daily / weekly / monthly and adjust the actual execution time by installing Dynamix Schedules) Quote Link to comment
_Shorty Posted January 7, 2018 Share Posted January 7, 2018 What are possible reasons for wanting to delay updates for x amount of days? I don't understand why one might want to do so. Hopefully someone can enlighten me. Thanks. Quote Link to comment
bonienl Posted January 7, 2018 Share Posted January 7, 2018 People are people and occasionally make mistakes. Doing immediate updates puts you in the fire zone and some users want to be more cautious, wait for the first results and update only when safe. Quote Link to comment
pwm Posted January 7, 2018 Share Posted January 7, 2018 7 minutes ago, bonienl said: People are people and occasionally make mistakes. Doing immediate updates puts you in the fire zone and some users want to be more cautious, wait for the first results and update only when safe. Exactly - when new versions are released for Android apps, I wait and read the most recent comments before I upgrade. That has saved me from quite a number of serious bugs - and also means I have old but working versions after the author decided to move some of the functionality into a payed version. Quote Link to comment
wgstarks Posted January 7, 2018 Share Posted January 7, 2018 2 hours ago, bonienl said: People are people and occasionally make mistakes. Doing immediate updates puts you in the fire zone and some users want to be more cautious, wait for the first results and update only when safe. I’ve wondered about this for a while. I understand the “canary period” idea, but after the waiting period will the 3 day old version be installed or will it be the most recent version (which has the same chance of being flawed)? Quote Link to comment
Squid Posted January 7, 2018 Author Share Posted January 7, 2018 1 hour ago, wgstarks said: I’ve wondered about this for a while. I understand the “canary period” idea, but after the waiting period will the 3 day old version be installed or will it be the most recent version (which has the same chance of being flawed)? The plugin only ever installs the latest version. So, if you're running a version from last year, and Jan 5 an update was issued and another on Jan 7, with a 3 day waiting period you will only get the version from January 7 when the plugin runs on January 11th. The January 5th version will never get installed. Quote Link to comment
JonathanM Posted January 7, 2018 Share Posted January 7, 2018 3 hours ago, wgstarks said: I’ve wondered about this for a while. I understand the “canary period” idea, but after the waiting period will the 3 day old version be installed or will it be the most recent version (which has the same chance of being flawed)? Typically in a responsive environment the buggy versions are pretty short lived. So, if you delay updates, hopefully the chances are better that you will land in a more stable period. So, when an update lands, it starts the timer, then when the timer expires, hopefully any interim bugs have been found and squashed in the version you end up downloading. Quote Link to comment
Squid Posted January 7, 2018 Author Share Posted January 7, 2018 13 minutes ago, jonathanm said: So, when an update lands, it starts the timer, then when the timer expires, Not 100% sure if I'm reading wrong or you got it wrong. Timer starts over without ever installing a previous version where the timer did not under expire. Quote Link to comment
wgstarks Posted January 7, 2018 Share Posted January 7, 2018 10 minutes ago, jonathanm said: Typically in a responsive environment the buggy versions are pretty short lived. So, if you delay updates, hopefully the chances are better that you will land in a more stable period. So, when an update lands, it starts the timer, then when the timer expires, hopefully any interim bugs have been found and squashed in the version you end up downloading. Yeah. I get that. What I was more worried about is that some authors tend to put out rapid updates. Sometimes several in one day. If they released an update 3 days ago it wouldn't necessarily be that update that got installed. Could be the update they released 5 minutes ago which contained an undiscovered bug. I hope no one thinks I'm complaining and I'm not pointing any fingers. Just being curious about how the process works. Quote Link to comment
Squid Posted January 7, 2018 Author Share Posted January 7, 2018 1 minute ago, wgstarks said: Sometimes several in one day What me!?!? Never As stated, the only update the plugin will install is the latest version that has been available for at least x number of days. Interim updates are ignored regardless if they meet the qualifications or not. Quote Link to comment
wgstarks Posted January 7, 2018 Share Posted January 7, 2018 1 minute ago, Squid said: What me!?!? Never Like I said, no fingers and no complaints. Was just always a little curious about this. Quote Link to comment
Squid Posted January 7, 2018 Author Share Posted January 7, 2018 As an aside while we're talking about it this, certain plugins (AKAIK only ControlR from @jbrodriguez) will never get updated by the plugin. This is because their version numbers instead of being dates etc are instead "real" version numbers. This is logged in the syslog when the plugin can't make sense of it. 1 Quote Link to comment
JonathanM Posted January 7, 2018 Share Posted January 7, 2018 5 hours ago, Squid said: Not 100% sure if I'm reading wrong or you got it wrong. Timer starts over without ever installing a previous version where the timer did not under expire. Huh? Can you please restate that last part in english? I'm not sure what a timer under expiring is, or how to interpret what I think you meant. It's very possible I understood wrong, I assumed when the plugin detects an update is available, it checks to see how long it's been available, and if the conditions aren't met, it ignores it. So only updates that have aged beyond the user configured delay are installed, hopefully allowing any zero day bugs to be detected and squashed in the version that ends up being installed. Quote Link to comment
pwm Posted January 7, 2018 Share Posted January 7, 2018 4 minutes ago, jonathanm said: Huh? Can you please restate that last part in english? I'm not sure what a timer under expiring is, or how to interpret what I think you meant. It's very possible I understood wrong, I assumed when the plugin detects an update is available, it checks to see how long it's been available, and if the conditions aren't met, it ignores it. So only updates that have aged beyond the user configured delay are installed, hopefully allowing any zero day bugs to be detected and squashed in the version that ends up being installed. He is saying that whenever a new release is published, then the timer is restarted. So if the timeout is set to 72 hours and an author releases a new version every day, then the timer will never reach 72 hours and no update will ever be installed for that application. It's only when the author stops pushing out new releases that the timer will run the full length and the plugin will be updated. Quote Link to comment
_Shorty Posted January 8, 2018 Share Posted January 8, 2018 Thanks for the responses. Makes great sense! Quote Link to comment
jbrodriguez Posted January 9, 2018 Share Posted January 9, 2018 On 1/7/2018 at 12:52 PM, Squid said: certain plugins (AKAIK only ControlR from jbrodriguez) will never get updated by the plugin Thanks for the heads up Squid. I'll look into having a date based version for unRAID plugin system / CA. Quote Link to comment
Squid Posted January 9, 2018 Author Share Posted January 9, 2018 1 hour ago, jbrodriguez said: Thanks for the heads up Squid. I'll look into having a date based version for unRAID plugin system / CA. Up to you. There is no problem with what you do. But simple for you to fix. Next update just switch the version listed in the .plg to be yyyy.mm.dd Quote Link to comment
jbrodriguez Posted January 11, 2018 Share Posted January 11, 2018 Squid, I switched to a date based version (unbalance plugin first), but the 'Check for Updates' process doesn't pick up the change. The plg file at https://github.com/jbrodriguez/unraid/blob/master/plugins/unbalance.plg, has the correct version: 2018.01.11 Any idea what can be wrong ? Quote Link to comment
Squid Posted January 11, 2018 Author Share Posted January 11, 2018 Something we didn't consider. 4.x.x is greater than 2018. Plugin manager does a simple string comparision. Guess you'll have to go back to the way things were. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.