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

 

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

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.)

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

 

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.

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

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)

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.

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.

 

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.

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)?

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.

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.

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.

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.

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.

1 minute ago, Squid said:

What me!?!?  Never  

Like I said, no fingers and no complaints.

 

Was just always a little curious about this.

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.

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.

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.

Thanks for the responses.  Makes great sense! 

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.

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

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 ?

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.