I've started receiving a lot of warning notifications from Parity Check Tuning, is there a way to resolve this?

Parity_Check_Tuning_1753862422.notify

Jul 30, 09:11

Parity_Check_Tuning_1753862422.notify

This notification is invalid and cannot be displayed! For details, see the logs and the notification file at /tmp/notifications/unread/Parity_Check_Tuning_1753862422.notify

Noticed a typo in the notifications that appears to be coming from PCT regarding an unclean shutdown:

should be documentation.

On 7/30/2025 at 4:15 AM, BurningSky said:

I've started receiving a lot of warning notifications from Parity Check Tuning, is there a way to resolve this?

Parity_Check_Tuning_1753862422.notify

Jul 30, 09:11

Parity_Check_Tuning_1753862422.notify

This notification is invalid and cannot be displayed! For details, see the logs and the notification file at /tmp/notifications/unread/Parity_Check_Tuning_1753862422.notify

I'm getting the same warnings seems to have started about 2 days ago.

hi,
after adding the plugin, i installed my parity drive. no parity existed before.
for simplicity, besides "use increments for scheduled/manual", also "automatic" is set to yes.
when the array starts the parity check in launched and this is tagged as "AUTOMATIC" in the progress file.

it is unclear to me at this point how exactly i can postpone this initial parity run to continue during other day(s) or as my system does not run 24/7.
shutting down/rebooting the system seems to reset everything back to zero.
am i overlooking something?

Edited August 16, 2025Aug 16 by Nuggetty

On 8/1/2025 at 3:19 PM, nemeth27 said:

I'm getting the same warnings seems to have started about 2 days ago.

Also started getting the warnings randomly

Parity_Check_Tuning_1755594021.notify

This notification is invalid and cannot be displayed! For details, see the logs and the notification file at /tmp/notifications/unread/Parity_Check_Tuning_1755594021.notify

Has anyone found a resolution for the notification error?

I think I've found a fix for now. It looks like the notification is malformed which is causing the error. It appears that the description line being blank is causing the issue for me, so I've added an if check to replace the description under the sendNotification in the parity.check.tuning.php file if it's blank:

global $parityTuningServer;
// Avoid invalid empty description
if (trim($desc) === "") {
$desc = "No details available.";
}

Edited August 29, 2025Aug 29 by BurningSky

Same issue here

But additionally - I've changed mover schedule to run every hour (I previously had it run once a day but was running low on cache space) and now I get a [...] Array operation not resumed - outside increment window alert every hour

It seems every time the mover stops, it checks to see if it can start the parity check and then sends an alert to say it isn't because it's outside of the parity check schedule... not particularly a helpful alert to be receiving on my phone every hour

I do not get how it's "not ready to use". I need some help.

(not sure if this is actively developed)

As for

On 9/2/2025 at 10:01 PM, xanderman21 said:

I do not get how it's "not ready to use". I need some help.

...they mean it is not implemented yet as a feature - and since it's there for a year or so, I am not sure they will implement it.

I have ANOTHER feature request in case someone is reading, a bit weird one:
A setting where if parity checking is finishing, but also getting to pause time, to be able to override this, so you don't get another day of check for mere minutes.
So for example it would look like this:

Do not pause if:

Percentage complete over: 95% (manual setting)

AND

Pause time is less than: 15 minutes away (manual setting)

...this will allow people to split the partial parity check way more easily.
In my case, parity check took 5 days, just because the 5th day it needs to cover like 3.5% to finish. Yes I could fine tune manually to increase time a bit, but then do it again if I replace a bigger disk, or some unforeseen traffic in the server slows down parity etc.

Edited September 4, 2025Sep 4 by NLS

On 8/16/2025 at 10:21 PM, Nuggetty said:

when the array starts the parity check in launched and this is tagged as "AUTOMATIC" in the progress file.

An automatic check is one that is started by Unraid if an unclean shutdown is detected. The next release of the plugin will tell you whether the reason for the unclean shutdown is the system crashing on not being able to cleanly stop the array.

On 8/16/2025 at 10:21 PM, Nuggetty said:

shutting down/rebooting the system seems to reset everything back to zero.

Have you set the option in the plugin to restart array operations from point reached the next time the array is started?

Note, however, that the restart only happens if the array was cleanly stopped. If you are getting automatic checks after a reboot then this is not the case and that will need resolving first.

On 9/2/2025 at 9:58 AM, PhilBarker said:

But additionally - I've changed mover schedule to run every hour (I previously had it run once a day but was running low on cache space) and now I get a [...] Array operation not resumed - outside increment window alert every hour

It seems every time the mover stops, it checks to see if it can start the parity check and then sends an alert to say it isn't because it's outside of the parity check schedule... not particularly a helpful alert to be receiving on my phone every hour

Not easy to see a way to detect that you sometimes want to be told about mover running and not others. Why not just switch off the "Send notifications for mover or backup running" option then you should not get any notifications of this sort? You can also disable the option to pause parity checks running when mover starts as an alternative. If you are running mover as frequently as hourly this might be sensible,.

7 hours ago, NLS said:

I have ANOTHER feature request in case someone is reading, a bit weird one:
A setting where if parity checking is finishing, but also getting to pause time, to be able to override this, so you don't get another day of check for mere minutes.
So for example it would look like this:

Do not pause if:

Percentage complete over: 95% (manual setting)

AND

Pause time is less than: 15 minutes away (manual setting)

...this will allow people to split the partial parity check way more easily.

Why not simply have an option to not pause if a certain % reached when the end of an increment time is reached. This should be easy to implement as is conceptually much simpler and seems to give basically the same benefit. Having said that I am not sure how much benefit this will really add as in most cases once you are splitting the check across multiple days then what is the big gain from finishing it a day earlier?

7 hours ago, NLS said:

.they mean it is not implemented yet as a feature - and since it's there for a year or so, I am not sure they will implement it.

That was not really meant to show to the average end user. It was only meant to show when I have set a special 'experimental' setting in the plugins .cfg file. The whole docker related feature has proved more problematical than expected so may never make it to general release. It is helpful when I AM running in experimental mode to see that prompt as in that mode the fields do need to be visible and it is a reminder there is potential work outstanding if this feature is ever going to progress further.

I AM making changes relating to the 7.2 release and the move to making the GUI responsive so there will be a release in the not too distant future so that should tidy up the above issue as I will make sure the prompt does not show until/if the feature is finally completed.

On 6/5/2025 at 3:27 PM, timid-stress8687 said:

Hi, the plugin seems to be restarting on my schedule rather than incrementing. I'm on unRAID 7.1.2 and it seems to be a recent issue as I've had it run successfully for about 2 years or so.

Not sure what you mean by this? As far as I know there should be no change to the plugins behaviour even on latest Unraid releases. Note that the plugin NEVER starts a check from the beginning - this only happens if the core Unraid system starts the check. When this happens there will be an entry in the syslog as a message from Unraid starting the check. If you think it IS the plugin then diagnostics captured while the plugin has the "Testing" level of logging enabled would allow me to confirm what is starting the check.

There have been a couple of instances where people have managed to set the standard Unraid settings to run at unexpected intervals. This shows up in the /etc/cron.d/root file in the entry after "# Generated parity check schedule:"

On 7/30/2025 at 9:15 AM, BurningSky said:

I've started receiving a lot of warning notifications from Parity Check Tuning, is there a way to resolve this?

Parity_Check_Tuning_1753862422.notify

Jul 30, 09:11

Parity_Check_Tuning_1753862422.notify

This notification is invalid and cannot be displayed! For details, see the logs and the notification file at /tmp/notifications/unread/Parity_Check_Tuning_1753862422.notify

I have not seen this in my testing. Any idea what the notification is about so I can see which one(s) needs looking at? If you know the approximate time then a syslog covering that would probably help pin it down.

19 hours ago, itimpi said:

Not easy to see a way to detect that you sometimes want to be told about mover running and not others. Why not just switch off the "Send notifications for mover or backup running" option then you should not get any notifications of this sort? You can also disable the option to pause parity checks running when mover starts as an alternative. If you are running mover as frequently as hourly this might be sensible,.

I should have led with that sorry

I have notifications for mover turned off, but still get them

Send notifications for mover or backup running: No
Send notifications for Pause or Resume of increments: Yes

I do want to be notified when the the job is paused due to schedule, and when the job restarts - I just don't want to be notified every time mover finishes and the job doesn't restart because of schedule.

I guess I could turn off the option to pause operation whilst mover is running, but it seems like that could cause a lot of load on the disks.

It's not a huge issue as I only get alert spam once a month, but seems like that particular notification doesn't fit within the "Pause or Resume" category?

7 minutes ago, PhilBarker said:

I have notifications for mover turned off, but still get them

Ok. That is a bug then that I need to look into for the next release. Now that I know what is happening should be easy to fix.

8 minutes ago, PhilBarker said:

I do want to be notified when the the job is paused due to schedule, and when the job restarts - I just don't want to be notified every time mover finishes and the job doesn't restart because of schedule.

That is why there are different settings in the plugin for the two scenarios as I could see the users wanting to treat them differently. Hopefully fixing the above issue will stop it being an annoyance.

On 9/4/2025 at 5:13 PM, itimpi said:

I have not seen this in my testing. Any idea what the notification is about so I can see which one(s) needs looking at? If you know the approximate time then a syslog covering that would probably help pin it down.

So based on what the addition to the script has done in the last day or so, these are the ones it looks like it has modified:

timestamp=1757126553
event=Parity Check Tuning
subject=[UNRAID] mover running
description=No details available.
importance=normal
link=/Settings/Scheduler

timestamp=1757149940
event=Parity Check Tuning
subject=[UNRAID] mover no longer running
description=No details available.
importance=normal
link=/Settings/Scheduler

timestamp=1757212942
event=Parity Check Tuning
subject=[UNRAID] mover running
description=No details available.
importance=normal
link=/Settings/Scheduler

timestamp=1757214031
event=Parity Check Tuning
subject=[UNRAID] backup running
description=No details available.
importance=normal
link=/Settings/Scheduler

timestamp=1757215478
event=Parity Check Tuning
subject=[UNRAID] backup no longer running
description=No details available.
importance=normal
link=/Settings/Scheduler

timestamp=1757215837
event=Parity Check Tuning
subject=[UNRAID] mover running
description=No details available.
importance=normal
link=/Settings/Scheduler

timestamp=1757231658
event=Parity Check Tuning
subject=[UNRAID] mover no longer running
description=No details available.
importance=normal
link=/Settings/Scheduler

timestamp=1757299365
event=Parity Check Tuning
subject=[UNRAID] mover running
description=No details available.
importance=normal
link=/Settings/Scheduler

But now I'm getting the same error on the native parity check it looks like:

Unraid_Parity_Check_1757236153.notify

Sep 8, 08:17
Unraid_Parity_Check_1757236153.notify

This notification is invalid and cannot be displayed! For details, see the logs and the notification file at /tmp/notifications/unread/Unraid_Parity_Check_1757236153.notify

17 minutes ago, BurningSky said:

So based on what the addition to the script has done in the last day or so, these are the ones it looks like it has modified:

These notifications are only meant to be displayed if both a parity check is in operation AND you have set the plugin setting "Send notifications for mover or backup running" to Yes. However a bug in the current release means they get displayed when they should not. This will be fixed for the release I am working on.

20 minutes ago, BurningSky said:

But now I'm getting the same error on the native parity check it looks like:

No idea about that. The notification is coming from the built-in code not from the plugin. What version of Unraid are you running so I can see if I can reproduce?

10 minutes ago, itimpi said:

These notifications are only meant to be displayed if both a parity check is in operation AND you have set the plugin setting "Send notifications for mover or backup running" to Yes. However a bug in the current release means they get displayed when they should not. This will be fixed for the release I am working on.

No idea about that. The notification is coming from the built-in code not from the plugin. What version of Unraid are you running so I can see if I can reproduce?

Is the recommendation to disable one when then other is enabled in that case? The second one only started happening today and, like you say, that's the default. I'm running Unraid 7.1.4 and 2024.08.16 for the plugin

1 minute ago, BurningSky said:

Is the recommendation to disable one when then other is enabled in that case?

Not quite sure what you mean? You need the default parity check enabled to specify when to start them in the first place. What you do NOT want is the Cumulative option set if the Parity Check Tuning plugin is handling increments.

Do you by any chance have the Cumulative option set in the standard settings? I add a check for that when you amend the plugin settings, but would not pick up it being set later - perhaps something I need to check for and warn about?

Weird, I typed a whole message and it only put the picture in so retyping the message...

Sorry, my question probably didn't make sense, you had said "both a parity check is in operation AND you have set the plugin setting "Send notifications for mover or backup running" to Yes" so I was just wondering if it was best practice to disable one of these?

It looks like cumulative option is set to no and greyed out, is that what you mean?

Edited September 14, 2025Sep 14 by BurningSky

My parity disk is 24 TB, and I live in an apartment that’s prone to power outages. A full parity sync takes about 6–7 days.

I was hoping that if a power outage occurred during a parity sync, this plugin would allow the process to resume from where it left off once the power came back. Unfortunately, that’s not the case: I was already 5 days into a sync when the power went out, and afterward I had to restart the entire sync from the beginning.

Right now, when the UPS shuts the server down, the parity sync is canceled instead of paused. That means I always have to start a new sync from scratch after power is restored.

I configured the plugin to run daily with a 5-minute pause, thinking it would resume the parity sync after a power outage.

Questions:

• Is there a way to pause a parity check during a power outage rather than having it canceled?

• Is there any way to tweak the system so that I can continue a parity sync from a known percentage (e.g., 73%) that was already reached in the previous run?

Edited September 24, 2025Sep 24 by Gico

On 9/8/2025 at 4:37 PM, itimpi said:

Not quite sure what you mean? You need the default parity check enabled to specify when to start them in the first place. What you do NOT want is the Cumulative option set if the Parity Check Tuning plugin is handling increments.

Do you by any chance have the Cumulative option set in the standard settings? I add a check for that when you amend the plugin settings, but would not pick up it being set later - perhaps something I need to check for and warn about?

The error has come back again, from the notifications panel:

Parity_Check_Tuning_1758855103.notify

26 Sept, 08:09
Parity_Check_Tuning_1758855103.notify

This notification is invalid and cannot be displayed! For details, see the logs and the notification file at /tmp/notifications/unread/Parity_Check_Tuning_1758855103.notify

And when I cat that message

~# cat /tmp/notifications/unread/Parity_Check_Tuning_1758855103.notify
timestamp=1758855103
event=Parity Check Tuning
subject=[RAGON] mover running
description=
importance=normal
link=/Settings/Scheduler

Looks like a blank description again so that might have been the cause. My change to the script to replace blank descriptions must have been overwritten