itimpi

The main reason is that if you do not have this plugin installed then you have some new columns (Elapsed Time and Increment Count) that would always Display an “Unknown” value as the fields would not be present in the history file. That is a valid reason although I was hoping it might not be seen as that important as they really are Unknown values in standard Unraid. I can work around my suggested change not being accepted by replacing the standard script for displaying history with my own customised version. That means that a future Unraid update could make an incompatible change, but since the script has not changed much in recent history maybe that is low risk. From an end-user perspective the two approaches are the same but I see having my own customised script as less elegant from a developer perspective. seperately I have had some feedback suggesting that adding a History button to the Settings page might be a good idea even if it merely displays the same history as available via the History button on the Main page. I can see some validity to that approach as you might well want to be able to easily examine history while playing around with settings relating to parity checking. i will push out an update tomorrow implementing both those changes. If later my proposed change to the standard script for displaying history gets accepted into Unraid I can always back out installing my own customised history script without affecting end-users.

Looks like my suggested change for enhancing the parity history displayed when clicking on the History button on the Main tab is going to be rejected so I will have to add my own History Hutton on the Settings page. I hope users will not get confused by the fact that the results shown by the Main page history button will show one set of Values (with some of them wrong) while my history button will show different (correct) ones for what is the same parity check.

The additional fields are not displayed with this update but the corrected duration and speed are displayed using the current history capability on the Main page. These additional fields ae being stored though for future use. If you want to examine the fields you can do it manually by looking in the /boot/config/parity-checks.log file as it is only a text file (once you have run a parity check to get them populated by the plugin). If my requested change to the built-in method of displaying history from the Main page is accepted these additional fields will be displayed from the History option on the Main page at the next Unraid release. I am hoping that it will be accepted as this would be the tidiest implementation and the suggested change does not cause problems if the Parity Check Tuning plugin is not installed. As I said if the change is rejected then I will issue an update to the plugin to add a 'History' button on the Settings page. I guess I could add it there anyway, but I would prefer not to as that just adds something else that has to be maintained and kept up-to-date. It also seems sensible to only have one way of displaying history - not two different ones that display slightly different information. I will wait on feedback from others to see what they think. I wanted to get this update out to start at least gathering this additional history information. After all parity checks are not something that one runs frequently and tend to take a long time to complete

I have released an update that implements the collection of history across a parity check that is run in increments. The standard system parity check log is then updated to give the correct values for the duration and average speed (up to now the values displayed have only been for the last increment). The plugin is also adding the total elapsed time and the number of increments to the history information. At the moment these additional items are not being displayed by the standard built-in Unraid option to display parity history. I have submitted a pull request on GitHub to see if displaying these extra fields can be implemented as a built-in feature of Unraid going forward. If not I will release an update to the plugin that adds a History button on the settings page.

Please do so. I have been asking for a similar facility for audiobooks (I.e. read book ‘’x’ by ‘y’ as it is not unusual for different authors to have used the same title. It can be difficult in such a case to get the particular audiobook I want to play. If in doubt I want the artist/author field to have higher priority than the album/book in such a request. At the programming level a ‘book’ should be equivalent to an ‘album’ and an ‘artist’ should be equivalent to an ‘author’ so I think they are two different manifestations of the same requirement. The alternative would be for some way of selecting an artist/author, and then drilling down to the albums/books that are available

I actually went for the $10/per year option which allows for 2 servers as I have music and audiobooks set up as separate servers (via 2 instances of the docker running on Unraid). I actually got the MyMediaForAlexa people to add a few features to make running multiple servers more user friendly.

Shame I do not get a free license for putting the template together Having said that I have not asked them so maybe I should ?

I have had no problems using it within the home on my local LAN. I do not try it in the mode where you are trying to use a remote Alexa device to try and access your home music - there have been reports of some limitations with running in that mode. In simplistic terms I would say it rather like using Amazon Music on Alexa, but for your own locally hosted media. One limitation is that the option to play multi-room (i.e. in 'everywhere' mode) is not supported but this is due to Amazon not yet making that capability available to third parties. You can try it for free for a week before you have to decide whether to buy a license to continue using it (and the license is not exactly expensive at $5 per year) so why not give it a try.

6.6.7 is the latest Stable release. 6.7.0 is still in rc stage (currently rc7) although it is expected to go Stable soon. If you want to try 6.7.0 rc7 then it is available via the Bug Reports->Prereleases section of the forum. The plugin needs a new feature that is coming as part of the 6.7.0 release for its operation.

As was mentioned you need to be on a 6.7 release for this to show up. I think at one point it was incorrectly showing up in CA for earlier Unraid releases. I added a check so that if you managed to install on an older Unraid release then users who navigate to the Settings->Scheduler tab will now find that although the fields for the plugin are shown the user cannot switch on the options with an error message displayed indicating they are not running a release of Unraid that allows this plugin to work as intended.

Perl and Python are not part of the standard Unraid install. They can be installed via the Nerd Pack plugin but if you are running in Safe Mode then all plugins are disabled.

A parity rebuild is the default if you have just done a New Config. you can force it at any other time by: stop the array unassign a parity disk start the array to make Unraid ‘forget’ the parity disk stop the array reassign the parity disk start the array and the system will start building the parity disk from the contents of the other disks. This is basically the same as the process that is used to force a data disk to be rebuilt to itself, but just applied to a parity disk instead.

I have seen cases where using a different VNC client can be better rather than the web based one built into Unraid. I personally tend to use realVNC running on Windows or a Raspberry Pi as my client.

forum support is by community members although Limetech staff do occasionally drop in and provide advice. You should never assume, though, that Limetech staff will necessarily see problems raised on the forum. On the whole the forum advice is good but it does depend on the exact experience of the particular forum members. The normal formal route is via email to Limetech (contact details at bottom of forum pages), and as far as I know the type of license you have is not relevant. Limetech also provide paid hands-on support at an hourly rate but that is probably more expensive than you want to go.

It is NOT built in. If is certainly something I would like to have. At the moment the VM service is only fired up when the array is started. If you stop the array then the VM service gets shut down. In most cases this does not matter as most people have their arrays set to auto-start when Unraid loads and only stop the array when they are shutting down (or rebooting) the server. However there are times where it would be convenient to be able to stop the array and keep a VM running (if it does not need access to any array or cache disks).

Have you encountered for the potential 30 minute delay (with default poll settings) before the GUI updates these settings? You can always reduced the poll interval (I have reduced mine to 5 minutes) if you want but on some systems the polling results in disk being spun up.

That is assuming that you need that powerful Raspberry Pi for the intended use? It sounded to me that even a Pi Zero W might be enough and that comes in at only $10.

I observed the same behaviour. Perhaps the change to that flag makes flushing the data to the USB drive largely happen before you get to the point of running the explicit 'sync' command? If so then you probably need a message added to the update process to say that you are transferring the files to the USB drive just before you start doing so?

If there is any heavy disk activity going on it slows down the sync stage. I have heard of a running pre-Clear make it take hours

UnRAID only takes into account the last increment when calculating speed. This can be widely misleading as far as speed is concerned as often it is just reading the parity disk (or fastest array disks) at that point. Also I have a feeling it thinks it checked the whole of parity in the time it took to run the last increment. In other words it does not take into account that the check has been paused and resumed a number of times. The one feature for the plugin that I still need to complete is for the plugin to provide its own history which will include tracking both running and paused time. This will allow for a more realistic calculation of average speed and will also tell you about total elapsed time.

The Min Free Space for the cache drive is not set at the User Share Level. instead you set it under Settings => Global Share Settings.

That is why I submitted as a ‘pull’ request to the Limetech wegui github repository rather than getting the plugin to try and patch the relevant file. Doing it that way as long as the ‘pull’ request is accepted by Limetech it will automatically be incorporated into the next Unraid build.

The change turned out to be trivial so I have sent a pull request on the Unraid webgui GitHub repository that will display something like the following when an operation is paused. I think this is a good solution that should work well?

Glad to here that it appears to be working as expected. i have raised a feature request to suggest that when a parity check is paused this is indicated in the Status line (I.e. the same message as when running but with ‘(paused)’ added on the end). That seems the right/best way to handle this and keeps the fact the operation is incomplete easily visible. I could look into doing it myself if nothing materialises but it might involve amending one of the main built-in Unraid scripts which I would rather not do as it might be prone to breaking things on an Unraid update which would be very bad news. If you think it would add value to add it to the Settings page that would be quite trivial to do. In fact in the early stages of the development of the plugin when I was trying to work out how to detect array status I actually had it there but thought it did not add much value so removed it to keep things cleaner.

This is not a problem but expected behaviour. The Stop button will be available once the BTRFS operation has completed. It has always been the case that long running operation did not allow you to stop the array. Having said that I cannot see anything in the log that mentions such an operation being started. Did you trigger this yourself or was it triggered automatically in some way?