FlamongOle

I know that some hard drives might be way slower than others to load any SMART data. Often chucked drives seems to use quite a lot of time to get the data out (probably because they go in true standby mode/turn off or something). How many drives do you have, and what does "lsscsi -u -g" output? Also, maybe try to remove the plugin and reinstall it again to see if that helps, maybe it couldn't fetch all data from github for some reason (if that is possible). Installing it from the Apps page is technically the same thing as installing it directly via github.

It can currently only reverse the entire unit, but not grouped. It is planned for a future v2 design, but is not directly supported now. Best thing you can do now is to hide the tray numbers or simply ignore them.

Update 2019.05.02 Commit #67 - MINOR ISSUE/FEATURE: Disk slot assignments don't save properly - removed some confusion for empty tables. Disabled the empty slots when the locations table is empty.

Update 2019.04.29 Commit #65 - MINOR ISSUE: Checks an array before counting it. Issue appeared if no empty trays were available. Removed disklocation.plg file: use disklocation-master.plg instead. NB! If you don't receive this update, be sure you have installed this plugin with the correct file mentioned above. If you installed this via the Community Application plugin, then there's nothing to do. If you use the old file, uninstall the plugin and reinstall it again with the correct file. The old file has been deprecated for a while now.

NVME drives are likely not supported at all at this moment and I dunno if or when it will be. M.2 SATA drives would likely work (or running them as SATA from BIOS, but don't do that as that would be rather pointless). The value of listing these drives anyway are probably rather small as they are mainly directly attached to the motherboard - and rarely more than 2 (in use anyway). It might be a task for the future if these drives comes down to a storage value level, but the importance of replacing a faulty drive is rather more important with the main Unraid array (not cache) and other Raid arrays. Maybe in the future, and it would rather be a part of Design v2.0 which isn't even in the works. Right now this plugin is too dependent on output from "lsscsi"

As stated earlier for the same request: I cannot do that as the sub-design does not permit it in an easy way. Empty trays are simply marked as a number and nothing else and currently I won't add a second layer of empty number as it might conflict and corrupt existing databases.

I had nothing else to do while drinking my wonderful craft beers Now time to game and chill - fragging gets easier and easier more reduced I am Of course thank you for help and your effort!

Update 2019.03.10 Commit #63 - BUG: Removed harddrives did not show up in the Information list but got invisible instead. Commit #62 - MINOR ISSUE: Fix broken harddrive information. Parsing of lsscsi is redone.

I guess I have a solution now using some regexp and less modifications in general. As LUN is mainly not in use anymore, I just compress the Vendor ID into a "selfmade" LUN. Else it will rather check for the contents. Also fixed a bug I discovered, old removed drives will now be shown until removed manually under "Information" - will release this asap

I looked at it a bit, but I think I might try a different approach based upon your data. However I feel it is strange you get a fallback value of Vendor ID instead of "none" as I get for some drives not including LUN. Just for the sake, what Unraid version are you using?

That is a bit of a bummer. I thought LUN always would be found. I might try to parse and compare and do some more checks and make a fallback myself.

That does not look like the output of "lsscsi -u -g", or at least not the first output. The LUN should not be visible with "lsscsi", and the ATA+Model Name should not be visible with "lsscsi -u -g" Also it appears to add an underscore after some spaces after the Model Name. It does split on a \s+ flag, meaning single and multiple spaces/tabs will be split correctly if the output of lsscsi is. I must say it is interesting if this is your output with the "-u -g" flags. The device model and serial number your drive shows is good for creating a hash. I still question the serial number a bit, if you have multiple of this SPCC disk check if you have any matching serial numbers as well. In short; if the output is truly what you show above from the exact command "lsscsi -u -g", then I might think this can be a bug from the lsscsi program. I don't see why it should have a different output unless the drive itself messes up with the parsing of lsscsi. Sorry if I can't help you enough here right now, but keep me posted if you find something useful.

Some SSD's might not include enough information to make a unique checksum. It must include "model" and "serial number" - this is as far as I've seen always included, if it's not; it will fail. It might also cause the layout to be messed up like you show it. Another reason might be that you assigned devices to the tray slots before storing the actual layout. Please check the drives if they give at minimum model+serial number, serial number has to be unique. I know for a fact that some less known brands might just put in a lot of zeroes instead of an actual number and hence won't work with this script. It won't be able to assign them either in any way.

Update 2019.03.09 Commit #60 - MINOR ISSUE: Warranty info is repeated for empty or non configured devices. Fixed by defining a variable as null.

Update 2019.03.08 Commit #58 - BUG: Invalid argument supplied for foreach(). Check if it is an array before searching in it, else default to false. @Nightowl805 You can test this now and check if that resolves the error message. I might need to dig in a bit deeper into this if it's not resolved.

It's impossible for anyone to know where your drives are located as the configurations out there varies a lot, so you must assign them manually the first time. So no automagic is happening there. For the error it looks like it might detect a false blank or something odd in the SMART rotational data. I'll fix this later.

To make it more precise about this syntax error; this means the updated harddisk data like SMART status, hours, load cycle count etc. is not updated when refreshing/loading the page. It will destroy some of the benefits of this plugin, so I highly recommend to update Unraid to 6.6+ But I'll leave that up to you of course, but the plugin will not work as intended.

USB drives are not supported, it has to be accessible via SAS/SATA controller. It is a very bad practice to follow the device node in general as it might shift node, it might be added in the future for the configuration - but I see no real use for it when it is accessible at the front page which is the main page for the overview. I also want to keep the configuration page/list as small as possible. The wish item is a task for design v2.0, this will not happen anytime soon though. Meanwhile you have to play with tray overrides, like 1*6 tray, and 10 for total trays for override. At least you can then separate them a bit.

The installer script is now updated. No other additional changes has been made, so an update won't bring anything new. New requirements are Unraid 6.6.0 and above, front page is updated. If you have earlier versions, the development package needs to be installed instead. This will -not- fix the SQLite syntax error issues, but it will be possible to install the script. Check the first page for more info on howto swap between stable and development branch.

I looked into the unraid changelogs; The version which supports "UPSERT" came in SQLite version 3.24.0. This version got included in Unraid 6.6.0. I guess then I have to conclude that this plugin is compatible with Unraid 6.6+, I weren't aware of this as I normally don't deal with SQLite but MySQL/MariaDB.

I would highly suggest and recommend to get a new connector instead (or fix it if possible, maybe just slightly bad connection with the pins - swapping the cable might help as well). I do not intend to fix something which is really not broken, and adding comments for empty trays might mess up the database and it will require a stupid amount of coding to just get that. Sorry I can't help you with this, at least not with this design.

Empty trays does not contain any data at all, it is simply one number that defines the empty tray slot and nothing can be added to it. That's why you can't add or view the comments.

@radfx & @GeekMajic What you can try to check if the SMART data actually get read, is to set a higher delay for "SMART execution delay" The plugin setting is a delay to be sure it has closed enough SMART instances before running new ones. It is mainly a nasty hack to be sure PHP has closed the run before opening too many new ones simultaneously which smartmontools does not like. A busy system might need a higher value, try 500 and 1000 just for the fun of diagnostics. It will/might take longer time to load the page with higher values. You can also try to run time smartctl -X /dev/sgX in the terminal to check how long time it takes to execute a SMART read. NB! The time it takes to read, has no influence over the setting for the plugin itself other than real time. If this does not help, either SMART is reporting false data or the drive gives weird values.

Update 2019.02.18b Commit #53 - MINOR ISSUE: Found the actual line, checks for disksize value before calculating human readable size. This should hopefully fix the warning message you got earlier

Which version of the plugin do you have? This issue should have been fixed some time ago. Yet the SSD is displayed when it find no rotation and it should also check for another input regarding solid state, it might not be 100% but then I can't do so much about it yet until smartmontools gets their info a bit better.