S80_UK

I have a couple of them although I have not yet gone with the front-loading approach - my 4 in 3 cages load from the inside. I just don't bother with the drive screws and use old business cards to wedge one side of the drives so they don't rattle around. It's just a shame they don't make this case anymore - it would still be pretty good for home server use.

Meanwhile, back on topic... Thanks for this - I shall test accordingly and let you have my feedback in the coming days. I will start by uninstalling and clearing out any old files so that the new plug-in has a fresh start.

A couple of comments if I may... This plugin does not do the scheduling that you describe - that scheduling is a standard function of Unraid, as is the automatically run parity check after any unclean shutdown. This plugin allows a standard check to be split into parts with controlled suspend and resume timings as needed to help limit the effects of system slowdown. If the automatic check after an unclean shutdown is an issue for you, you should perhaps ask Limetech about it, although I suspect they would be reluctant to make it possible to disable the check from starting under those conditions (it kind of defeats the purpose). As noted above, you also do have the option to cancel a check, and with the plugin, you have the option to pause it. As for not worrying about dirty parity, that would depend on the value of your data and the frequency of your scheduled checks, as well as the reliability of any backup scheme that you might have. Don't forget that dirty parity will prevent Unraid from correctly recovering a disk if it fails before the parity error is detected and corrected. Personally, I would prefer to have the automatic check run after an unclean shutdown and restart. Then I can make an informed decision on whether to abort or let the check complete. As @jonathanm has commented - a UPS may be a better approach if you have frequent unscheduled restarts (unless they are due to causes other than mains power).

Thanks for the latest update - from the change log it looks like there was a lot of work on that one. I don't use this plug-in that often, but when I do it's great to have a tool such as this that "just works". Much appreciated. Thank you.

Ok, cool. I look forward to the next update - take your time. Thanks.

Hi @itimpi So, last night I ran a manual check with the threshold temperatures set higher to avoid any temperature related pause. That worked up to the point where a pause would be expected for a scheduled check. At 08:00 the check was paused, even though this check was manual and no paused was expected. Currently it is paused at about 73%. I am attaching the files requested. Also attached is a diagnostics capture (just now). Please let me know if you need any more info. parity.check.tuning.cron parity.check.tuning.progress parity.check.tuning.scheduled parity.check.tuning.cfg tower-v6-diagnostics-20210221-1146.zip

Understood - I will grab what I can.

Thanks for the reply. The resumed check completed without errors. I may try to repeat the process tonight, but with the temperature threshold set a little higher to avoid an unplanned pause. I can then try again after that with a lower threshold to see what happens. I shall let you know how it goes.

Hi! I am happy to give a little feedback after a couple of passes through the process with this new version. I set up a scheduled check earlier in the week which paused and resumed perfectly. That was a couple of days ago. Yesterday, I had an unplanned user created hardware issue - my HBA went off-line taking six drives out of the array at once. This was a mechanical problem caused by the card not sitting properly in the PCIe slot. I shut down the array, powered down and attended to the mechanical issues. Everything came up OK, and since I had shut down first, the array seemed good - Unraid did not try to run an automatic parity check. But due to the nature of the problem I felt that a parity check would be a good idea. So I started a check just after midnight. I did not have pause/resume enabled for manual checks. Two things then happened. At 01:28 the test paused due to an over-heating drive (it was at 42 degrees - a bit hotter than normal). At 02:00 it had cooled and the check resumed. By chance, 02:00 is also when I have the test start and resume if it's a scheduled check. The test then ran OK until 08:00 when it paused. However, the settings were such that it should not have paused for a manually run test. I manually resumed at around 10:35 this morning - I am just waiting for that to finish. So, all went well, but the manual parity check paused at 08:00 when it should not have (set to no pause for manual checks). I am wondering if this may have been a consequence of the pause and resume caused by an over temperature event several hour earlier. Perhaps a "pause enable flag" or something got set by this? From my point of view this is not a critical problem, but it looks as though something in the logic is still not quite right. I did not have test or debug logging running for this - I was more concerned with checking the array after my HBA issue earlier the previous day. So far, it appears that my hardware issue did not cause any disk corruption. I will be happy to try again if it helps. Cheers.

I tested the new version over the last couple of nights with a scheduled parity check with one pause. Everything worked correctly and the start and end notifications were as expected. Emails for start, pause, resume and finish were also sent. This is looking very good. Many thanks for the improvements. (I am running 6.9.0-rc2 btw.)

I shall PM the cfg file to you. I had not enabled for manual checks, but this was not a manual check - it was a scheduled check run at 2am in the morning using the regular parity check scheduler, so I would not have expected to need to enable the scheduler for manual checks for that purpose. Have I misunderstood how it works?

@itimpi So my parity check is still not pausing. Last night I did a run with test logging enabled. Syslog is attached. This was after a fresh install of the plugin, and after a fresh reboot of the server to try to eliminate any effects of earlier activity. The critical point is at line 4386 when the log shows the pause attempt like this... Jan 17 08:00:01 Tower-V6 parity.check.tuning.php: TESTING: ----------- PAUSE begin ------ Jan 17 08:00:01 Tower-V6 parity.check.tuning.php: TESTING: disk2 temp=*C, status=cool (drive settings: hot=42C, cool=35C) Jan 17 08:00:01 Tower-V6 parity.check.tuning.php: DEBUG: Pause request Jan 17 08:00:01 Tower-V6 parity.check.tuning.php: TESTING: disk3 temp=38C, status=warm (drive settings: hot=42C, cool=35C) Jan 17 08:00:01 Tower-V6 parity.check.tuning.php: DEBUG: ...action not configured for manual Non-Correcting Parity Check (check P) Jan 17 08:00:01 Tower-V6 parity.check.tuning.php: TESTING: disk4 temp=*C, status=cool (drive settings: hot=42C, cool=35C) Jan 17 08:00:01 Tower-V6 parity.check.tuning.php: TESTING: ----------- PAUSE end ------ The pause was configured for 08:00 - I have highlighted the obvious error report, but I have no clue as to the cause. The pause was then immediately cancelled and the parity check resumed and ran to completion nearly four hours later. Please let me know if there's anything else I can try. syslog.txt

I am on -RC2 as well, but I have not seen that error, although my parity check run is not pausing as expected.

Even if you could (I am not sure) I wouldn't recommend it. Specifically, if you have any parity drive in your system then the speed of transfer of files is going to be limited anyway by the need to read both the destination drive and the parity drive before the data is written and the parity updated. If you run two instances, then the parity drive will spend a lot of time moving the heads between the two areas that are being updated when you are unBalancing moving data to two separate data drives. The time lost would be much greater than when running the two sessions separately

OK - understood. Just thought I should check. That almost certainly was the case. Thanks again. OK - I will see how it goes. I can do some further testing after the weekend. (I am still doing disk upgrades at present and I'm letting the parity processes run to completion to get though it as fast as possible.) Thanks for the plug-in by the way - it is genuinely very useful.

Since I need to work on the server later in the week I decided to try uninstalling and re-installing the plugin - it had previously been updated on multiple occasions. Uninstall was uneventful. I decided to reboot the server before a clean install of the plugin. However, for reasons unknown the server rebooted and went straight into a parity check. I used the normal Reboot button in the web UI so I don't believe it should have done that. Anyway, I will now let that run through until tomorrow and then I have a couple of hard disks to swap around for a capacity upgrade, so I shall get back to this in a day or so.

Something strange... I updated the plugin three days ago to the current version (2021.01.03) (main server running 6.9.0-rc2). I did not touch the settings at that time which were to use increments, starting at 01:00, pausing at 08:00, repeat until done. Last night (first Wednesday in the month) the check started. The check was still running at 10:00 (should have paused at 08:00) and finished at 12:42. There was nothing in the syslog at the time that it should have paused, although I did not have debug logging enabled for the plugin. I did notice that the notifications for start and end of the check were duplicated. Previously I only ever had one of each. I also received two emails telling me that the check had finished - one titled "unRAID Status: Notice [TOWER-V6] - Parity check finished (0 errors)", the second titled "unRAID Status: Non-Correcting Parity Check finished (0 errors)". Previously I only had the usual start and finish emails. Would it be better to reinstall the plugin and try again, or would it be helpful if I could capture some debug logs? Or both?

Just for info - there are many keyboards with the Euro symbol - even my UK layout Logitech keyboard (over 10 years old) has it. In my case it's on the 4 key, along with the dollar sign. Control-Alt-4 gives € in this case. It's the same on my Dell laptop too. Or if don't have the key marked but you have a numeric keypad, press and hold Alt while pressing 0 1 2 8 - that would be the way that many less common characters can be entered (and that method goes right back to the days of using DOS for some of us).

As far as I am aware, for DVDs and normal HD blu-rays, MakeMKV does not have specific requirements (although I only use MakeMKV under Windows). If you need to rip 4K blu-rays, then MakeMKV has very specific requirements that the drive be one described as "UHD friendly". This thread on the MakeMKV forums gives pretty comprehensive details. https://makemkv.com/forum/viewtopic.php?f=16&t=19634 (Hope it's OK to link to there from here...) Note that for some drives, the firmware needs to be earlier than a specified version, and downgrading from later versions may not always be possible (lots of details in that thread). For what it's worth I use the Asus BW-16D1HT, but bought 2 or 3 years ago. Edit: I should add that I only rip to my server - I don't generally play from the optical drive. The only time the disc gets played properly is very rare and in the Blu-ray player under the TV...

@Maruco - You say that you have a small IT support company. In that case you would understand that support has to be paid for otherwise the support company does not make money and does not survive. It seems to me that your client has no right to expect any support for software that they have been using that they have not legitimately paid for. Equally, until tha situation changes, I would not expect anyone here to help either. Everyone on this forum who is a user of Unraid and a customer of Lime Technology has paid for their license. Most are home users and small businesses many of whom have paid for more than one license. We sometimes ask for help, we sometimes give help to others, but that is on the understanding that Unraid is the work of a very small company who cannot support all users individually and therefore we are happy to share our knowledge and experience. That goodwill is limited, however, and in my case would not extend to supporting anyone who is trying to profit from the work of others while trying to avoid payment. You say that your client is willing to purchase a license if you can repair their system? They already know that Unraid can do the job - they had it working before these problems. So they should buy a license and if they cannot solve the problems themselves then they could engage you to help them and pay you a reasonable fee for the work. As commented above this has already cost them money; and now it is costing you money. If they understand business, then they should understand this kind of support has to be paid for somehow. If they don't understand that, then in my view you should walk away.

Hi... I just thought I'd chip in with my expereince. I installed the daapd Docker a couple of months ago on my Unraid server to try it with my elderly Roku SoundBridge audio streamers. I still use them since they work extremely well, despite being 13 - 14 years old. I work in consumer audio so use I multiple server programs and I have been using Twonky Media Server and AssetUPnP for some years. Since Unraid went to 64 bit I have been unable to run the old Firefly Media Server which Roku used to recommend (it was 32 bit), but I always slightly preferred the user experience with Firefly over Twonky and was keen to get back to that. I had tried this daapd Docker in the past but without success. I cannot say whether the issues that I had previously were down to the software, or perhaps my lack of experience with Docker, but this time around I set it up without issues, and so far it "just works" and appears very stable. I have a reasonably large audio library (over 18,000 files, all ripped from CDs), and all well tagged. I have had no issues related to poor tagging, large album art, or the use of Chinese and other Asian character sets (I have almost 3000 such files). I did have one strange problem - I had one more file detected by the daapd scan than by the other servers. I found that it was picking up a duplicate file that had a filename extension that was not related to audio - something.tmp I think. So daapd was looking in files other than those with expected filenames such as .mp3, .m4a, etc. I just wonder whether the scanning of unrelated files might be tripping up the software for those users that have problems. In my case, I just removed the .tmp file and the total file count from the scan was then correct. For what it's worth, I am not using daapd with iTunes or other daapd clients than my SoundBridges.

I don't have the network card, but I was looking at one for a while, ended up using USB with MODBUS protocol. However, I found this thread that may help - looks like it can be made to work with the network card...

@civic95man - Thanks. Great to hear that it worked for you, and thanks for the additional guidance for others that may also need to apply this update to their UPS.

It's down to what version of firmware you currently have. If yours is recent, you will be OK to update, and you'll be able to select the MODBUS protocol which works just fine with complete reporting. See here for info on the supported firmware options... https://www.apc.com/us/en/faqs/content/?id=FA281865 Also here for some more background...

Hi Ian, I shall leave a review presently, not a problem. In the meantime, I have also just sent a set of logs from the app (attached to email, sent from the app). Again, let me know if you need anything further. Thanks.