[Plugin] CA Fix Common Problems


Recommended Posts

I got a warning last night telling me my server's time is out by approximately 40 minutes. It looks fine to me and the time hasn't changed.

Just ignore it.  I have to check the time against an internet server that reports the unix epoch time and if something happens on it then the error also results.  I just re-ran the tests and everything is ok, so whatever issues that server was having is now fixed.
Link to comment

I got a warning last night telling me my server's time is out by approximately 40 minutes. It looks fine to me and the time hasn't changed.

Just ignore it.  I have to check the time against an internet server that reports the unix epoch time and if something happens on it then the error also results.  I just re-ran the tests and everything is ok, so whatever issues that server was having is now fixed.

 

Another example, with a little more detail:

Aug 11 04:40:02 JacoBack logger: Fix Common Problems Version 2016.08.06

Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: Community Applications not set to auto update ** Ignored

Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: Dynamix WebUI not set to auto update ** Ignored

Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: This plugin (Fix Common Problems) not set to auto update ** Ignored

Aug 11 04:40:07 JacoBack logger: Fix Common Problems: Other Warning: Disk(s)  disk1  disk10  disk11  disk2  disk3  disk4  disk5  disk6  disk7  disk8  disk9  are spun down.  Skipping write check and HPA check

Aug 11 04:40:08 JacoBack logger: Community Applications Auto Update Running

...

Aug 12 04:40:02 JacoBack logger: Fix Common Problems Version 2016.08.06

Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: Community Applications not set to auto update ** Ignored

Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: Dynamix WebUI not set to auto update ** Ignored

Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: This plugin (Fix Common Problems) not set to auto update ** Ignored

Aug 12 04:40:06 JacoBack logger: Fix Common Problems: Warning: Your server's current time differs from the actual time by more than 5 minutes.  Currently out by approximately 308 minutes

Aug 12 04:40:08 JacoBack logger: Fix Common Problems: Other Warning: Disk(s)  disk1  disk10  disk11  disk2  disk3  disk4  disk5  disk6  disk7  disk8  disk9  are spun down.  Skipping write check and HPA check

Aug 12 04:40:12 JacoBack logger: Community Applications Auto Update Running

Aug 12 09:47:10 JacoBack emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin checkall

 

No problem on Aug 11, claims clock off by 5 hours 8 minutes (so not a timezone issue) on Aug 12.  Noticed this message about 9:30am, did a plugin check at 9:47am just to put a timestamp into log, and it was perfect.  No apparent clock corrections, just a check against the wrong time (under some condition, randomly generated?).  (still on 6.1.9)

Link to comment

I got a warning last night telling me my server's time is out by approximately 40 minutes. It looks fine to me and the time hasn't changed.

Just ignore it.  I have to check the time against an internet server that reports the unix epoch time and if something happens on it then the error also results.  I just re-ran the tests and everything is ok, so whatever issues that server was having is now fixed.

 

Another example, with a little more detail:

Aug 11 04:40:02 JacoBack logger: Fix Common Problems Version 2016.08.06

Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: Community Applications not set to auto update ** Ignored

Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: Dynamix WebUI not set to auto update ** Ignored

Aug 11 04:40:02 JacoBack logger: Fix Common Problems: Warning: This plugin (Fix Common Problems) not set to auto update ** Ignored

Aug 11 04:40:07 JacoBack logger: Fix Common Problems: Other Warning: Disk(s)  disk1  disk10  disk11  disk2  disk3  disk4  disk5  disk6  disk7  disk8  disk9  are spun down.  Skipping write check and HPA check

Aug 11 04:40:08 JacoBack logger: Community Applications Auto Update Running

...

Aug 12 04:40:02 JacoBack logger: Fix Common Problems Version 2016.08.06

Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: Community Applications not set to auto update ** Ignored

Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: Dynamix WebUI not set to auto update ** Ignored

Aug 12 04:40:03 JacoBack logger: Fix Common Problems: Warning: This plugin (Fix Common Problems) not set to auto update ** Ignored

Aug 12 04:40:06 JacoBack logger: Fix Common Problems: Warning: Your server's current time differs from the actual time by more than 5 minutes.  Currently out by approximately 308 minutes

Aug 12 04:40:08 JacoBack logger: Fix Common Problems: Other Warning: Disk(s)  disk1  disk10  disk11  disk2  disk3  disk4  disk5  disk6  disk7  disk8  disk9  are spun down.  Skipping write check and HPA check

Aug 12 04:40:12 JacoBack logger: Community Applications Auto Update Running

Aug 12 09:47:10 JacoBack emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin checkall

 

No problem on Aug 11, claims clock off by 5 hours 8 minutes (so not a timezone issue) on Aug 12.  Noticed this message about 9:30am, did a plugin check at 9:47am just to put a timestamp into log, and it was perfect.  No apparent clock corrections, just a check against the wrong time (under some condition, randomly generated?).  (still on 6.1.9)

It's never going to be a time zone issue as I'm comparing Unix epoch times.  But rather its an issue on the time server's end.  I'll look around for another server that suits my needs or modify the code to issue it as an other warning or something.

 

Sent from my LG-D852 using Tapatalk

 

 

Link to comment

Squid,

 

    I looked to see if this was covered in the postings some where but I am did not find it. Are these a false positive or something I need to really look at?  They are under "other comments" so I was not sure before ignoring them.

 

Could not perform unknown plugins installed checks The download of the application feed failed.

Could not perform docker application port tests The download of the application feed failed.

 

Thanks for a great plugin!

 

Greg

Link to comment

Squid,

 

    I looked to see if this was covered in the postings some where but I am did not find it. Are these a false positive or something I need to really look at?  They are under "other comments" so I was not sure before ignoring them.

 

Could not perform unknown plugins installed checks The download of the application feed failed.

Could not perform docker application port tests The download of the application feed failed.

 

Thanks for a great plugin!

 

Greg

Its exactly what it says.  FCP was unable to download an application feed (the same feed which CA uses), so it couldn't perform those tests.  Usually in conjunction with this there are also errors about connectivity, but occasionally there are not (due to various other factors such as your VPN provider blocking cloudfare, etc)

 

Link to comment
  • 2 weeks later...

I have a problem with Fix Common Problems.  Any time the plugin is opened, its spins up all the discs and starts scanning.  This scanning message "hangs' (i.e the scanning message never goes away even after hours) the WebGUI and it is unavailable unless I close it and reopen it in a different browser tab. 

 

Am I just being impatient?  Should it take several hours checking permissions?  I do have over 120,000 photos and videos stored on the server.

 

I cannot configure the plugin as it immediately starts scanning whenever opened and never finishes.  As you can see, I am running unRAID 6.1.9 and the version of FCP is the latest (2016.09.04) although this has been happening for at least a month before it was updated today to the latest.

 

Diagnostics attached in case it is helpful.

 

See screenshot:

 

w7n28k.jpg

medianas-diagnostics-20160905-1101.zip

Link to comment

Works fine for me.  What browser are you using?

 

Sent from my LG-D852 using Tapatalk

 

Firefox 48.0.2

 

Just tried it on Chrome, same thing.  Tried it on Edge, same thing.  Of course, I did not let FCP run for hours, but, in all browsers, it starts scanning immediately when started and I cannot configure the plugin as it "hangs" on scanning.

 

I just attached diagnostics to original post if helpful.

 

This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10.  I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that stated around the time of the upgrade as well.  Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install.  I doubt this has anything to do with it, but, just to eliminate a variable, I will try it.

Link to comment

Works fine for me.  What browser are you using?

 

Sent from my LG-D852 using Tapatalk

This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10.  I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that started around the time of the upgrade as well.  Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install.  I doubt this has anything to do with it, but, just to eliminate a variable, I will try it.

 

Well, what do you know?  It appears that is, in fact, the root of the problem.  On my laptop with fresh Windows 10 install, no issues with FCP and text shows up in update windows in plugins and docker tabs.  Why my "upgrade" installation of Windows 10 causes this functionality/display issue in FCP, I have no ideas; however, that appears to be the cause.

 

No errors or warnings were found with the FCP scan from my laptop, so, that is also good news  :)

Link to comment

Works fine for me.  What browser are you using?

 

Sent from my LG-D852 using Tapatalk

This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10.  I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that started around the time of the upgrade as well.  Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install.  I doubt this has anything to do with it, but, just to eliminate a variable, I will try it.

 

Well, what do you know?  It appears that is, in fact, the root of the problem.  On my laptop with fresh Windows 10 install, no issues with FCP and text shows up in update windows in plugins and docker tabs.  Why my "upgrade" installation of Windows 10 causes this functionality/display issue in FCP, I have no ideas; however, that appears to be the cause.

 

No errors or warnings were found with the FCP scan from my laptop, so, that is also good news  :)

It may infact be a bug.  While I can't recreate it your behaviour, I would hazard a guess that your desktop has adblockers installed, while the laptop does not.

 

FCP throws up a popup if an adblocker is detected, but if its never been run before on top of that it throws up the Scanning popup.  On mine under those circumstances, both the popups wind up being closed at the conclusion of the scan, but for some reason yours might be different (no idea why).  I'll rearrange the order of the tests.

 

Link to comment

Works fine for me.  What browser are you using?

 

Sent from my LG-D852 using Tapatalk

This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10.  I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that started around the time of the upgrade as well.  Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install.  I doubt this has anything to do with it, but, just to eliminate a variable, I will try it.

 

Well, what do you know?  It appears that is, in fact, the root of the problem.  On my laptop with fresh Windows 10 install, no issues with FCP and text shows up in update windows in plugins and docker tabs.  Why my "upgrade" installation of Windows 10 causes this functionality/display issue in FCP, I have no ideas; however, that appears to be the cause.

 

No errors or warnings were found with the FCP scan from my laptop, so, that is also good news  :)

It may infact be a bug.  While I can't recreate it your behaviour, I would hazard a guess that your desktop has adblockers installed, while the laptop does not.

 

FCP throws up a popup if an adblocker is detected, but if its never been run before on top of that it throws up the Scanning popup.  On mine under those circumstances, both the popups wind up being closed at the conclusion of the scan, but for some reason yours might be different (no idea why).  I'll rearrange the order of the tests.

 

Hmmm.... interesting theory.  I do have Adblock+ installed in Firefox; however, it is installed on both the laptop and the desktop.  My successful run of FCP on the laptop was with Firefox with ABP installed and enabled.  No popup blockers were manually installed for Chrome or Edge on the desktop and FCP failed in the same way on both of those browsers as well.  I also disabled the Edge built in popup blocker and saw the same behavior.

 

I then disabled ABP in Firefox and ran FCP again on the desktop; same result. 

Link to comment

Works fine for me.  What browser are you using?

 

Sent from my LG-D852 using Tapatalk

This problem may have started when I "upgraded" my PC from Windows 7 to Windows 10.  I have also noticed, that when installing Docker updates or checking for plugin updates, the pop-up status window is more often than not blank until the process finishes. I am fairly certain that started around the time of the upgrade as well.  Just for kicks, I'll check it out on my laptop which has a fresh Windows 10 install.  I doubt this has anything to do with it, but, just to eliminate a variable, I will try it.

 

Well, what do you know?  It appears that is, in fact, the root of the problem.  On my laptop with fresh Windows 10 install, no issues with FCP and text shows up in update windows in plugins and docker tabs.  Why my "upgrade" installation of Windows 10 causes this functionality/display issue in FCP, I have no ideas; however, that appears to be the cause.

 

No errors or warnings were found with the FCP scan from my laptop, so, that is also good news  :)

It may infact be a bug.  While I can't recreate it your behaviour, I would hazard a guess that your desktop has adblockers installed, while the laptop does not.

 

FCP throws up a popup if an adblocker is detected, but if its never been run before on top of that it throws up the Scanning popup.  On mine under those circumstances, both the popups wind up being closed at the conclusion of the scan, but for some reason yours might be different (no idea why).  I'll rearrange the order of the tests.

 

Hmmm.... interesting theory.  I do have Adblock+ installed in Firefox; however, it is installed on both the laptop and the desktop.  My successful run of FCP on the laptop was with Firefox with ABP installed and enabled.  No popup blockers were manually installed for Chrome or Edge on the desktop and FCP failed in the same way on both of those browsers as well.  I also disabled the Edge built in popup blocker and saw the same behavior.

 

I then disabled ABP in Firefox and ran FCP again on the desktop; same result.

Then I don't have any good answers.  I'll still rearrange the order of things being done however.
Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

ok.  This what I'll do then.

 

I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all)

 

If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1)

 

Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it.  That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error.

Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

ok.  This what I'll do then.

 

I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all)

 

If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1)

 

Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it.  That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error.

 

That's a plan.

 

I know some people still want to use it, but it has become increasingly difficult to chase down the changes in the shutdown scheme LT implements in each version and for me to try to keep up.  LT has also improved the shutdown in 6.2 and does not rely on emhttp for the shutdown which is where the process would get stuck waiting for something to happen/complete.

 

In 6.1 dockers and VMs were shutdown by the unmounting events.  In 6.2 the dockers and VMs are shut down with explicit calls for a shutdown.

 

I've suggested a few changes to the built in shutdown and if they do those, there is not much need at all for the powerdown script.

Link to comment

- Updated with the downgrade in alert level for powerdown not installed

- Fixed a race condition if an ad-blocker was installed, and no errors were found on previous scan (or if first scan after a reboot) by going to an (ugh) old-school style alert for ad-blockers

- faster downloads on the application feed (and more checks if its complete)

 

Link to comment

Hi,

 

I've been using the beta 6.2 for a while now. Now that I upgraded to 6.2 stable its detecting this problem:

 

docker appdata location is stored within /mnt/user

 

 

Many (if not most) docker applications will have issues (weird results, not starting, etc) if their appdata is stored within a user share. You should constrain the appdata share to a singledisk or to the cache drive. This is true even if the appdata share is a Cache-Only share.

 

Is this an actual error? Because the location of /mnt/user was done by Unraid automatically.

Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

ok.  This what I'll do then.

 

I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all)

 

If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1)

 

Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it.  That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error.

 

Powerdown will not install on v6.2 any more.  I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install.

 

It is no longer necessary.

Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

ok.  This what I'll do then.

 

I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all)

 

If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1)

 

Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it.  That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error.

 

Powerdown will not install on v6.2 any more.  I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install.

 

It is no longer necessary.

Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2)

 

Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

ok.  This what I'll do then.

 

I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all)

 

If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1)

 

Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it.  That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error.

 

Powerdown will not install on v6.2 any more.  I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install.

 

It is no longer necessary.

Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2)

Just read it a bit closer.  Did you set it to 6.1 or 6.1.9  Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs)
Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

ok.  This what I'll do then.

 

I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all)

 

If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1)

 

Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it.  That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error.

 

Powerdown will not install on v6.2 any more.  I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install.

 

It is no longer necessary.

Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2)

Just read it a bit closer.  Did you set it to 6.1 or 6.1.9  Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs)

 

6.1.

Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

ok.  This what I'll do then.

 

I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all)

 

If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1)

 

Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it.  That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error.

 

Powerdown will not install on v6.2 any more.  I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install.

 

It is no longer necessary.

Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2)

Just read it a bit closer.  Did you set it to 6.1 or 6.1.9  Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs)

 

6.1.

Should probably change it then
Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

ok.  This what I'll do then.

 

I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all)

 

If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1)

 

Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it.  That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error.

 

Powerdown will not install on v6.2 any more.  I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install.

 

It is no longer necessary.

Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2)

Just read it a bit closer.  Did you set it to 6.1 or 6.1.9  Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs)

 

6.1.

Should probably change it then

 

Done.  Set to 6.1.9.  As I understand, that is the max version CA will allow and FCP will check.

Link to comment

The powerdown script built into v6.2 is vastly improved over the v6.1 script and does a good job at shutting down the server without hanging up in an endless loop.  The powerdown plugin offers some advantages such as K and S script processing on shutdown and start up (although these situations can be handled as well now with the user_scripts plugin), more extensive shutdown logging, and archiving of logs.

 

Where I am going with this is I think you should suggest the powerdown script as an option (or say nothing at all) and not show it as a must have plugin.  It's not as necessary now as on earlier versions.

 

As LT improves the shutdown process, I can see the powerdown script no longer necessary on later versions and I would like to eventually deprecate the plugin.  I am thinking that I'll block its install on versions later than v6.2.  I have been uncomfortable with taking over the unRAID shutdown process and I doubt I'll want to invest more time in the plugin in the future.

ok.  This what I'll do then.

 

I'll downgrade the level of powerdown not being installed from an error to a warning (although it is still very commonly told to users to install it whenever there are any sort of issues at all)

 

If/when you block its installation on 6.2 then I'll adjust FCP to not complain at all if the user is running 6.2 (and leave the warning on 6.1)

 

Additionally, when you block its installation, adjust the plugin xml with the <MaxVer> on it.  That way CA won't offer it to people at all on 6.2, and if FCP finds it installed (installed prior to you deprecating it and after upgrading to the blocked version of unRaid) then it will generate an error.

 

Powerdown will not install on v6.2 any more.  I've added the <MaxVer> tag to 6.1 so CA will no longer show it as a plugin to install.

 

It is no longer necessary.

Sure... let me know right after I release an update to adjust for the fact that the RC candidates were 6.2.0-RCx and final is 6.2 (technically, 6.2.0-RCx is a later release than 6.2)

Just read it a bit closer.  Did you set it to 6.1 or 6.1.9  Big difference there, as both CA and FCP take into account point releases (along with Betas and RCs)

 

6.1.

Should probably change it then

 

Done.  Set to 6.1.9.  As I understand, that is the max version CA will allow and FCP will check.

Correct.  And CA is already flagging it as incompatible on my 6.2 system and my 6.1.9 system its ok.

 

Just have to reconfigure FCP and we're good to go.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.