jbartlett

The unable to upload images is a known issue that's been annoying the heck out of me. The right side is in an iframe and if it launches the upload dialog there, it's limited to that frame and not the entire browser window. The code running in the iframe updates a div block in the main window with a button to launch it but nothing I do activates the click event on it, even though every resource I've found says it should. I decided to release it with that issue so everything else could be tested while I applied percussive techniques to the issue.

Please update the app and try again. I put an existence check on the delete of submitted.txt which caught the scenario where a benchmark was done but wasn't previously uploaded. eurlin, still looking into your issue.

That's really odd. I can't duplicate and that shouldn't happen. You've got something weird going on with your setup. if you could, please use update the Docker and run again. When you get the error, replace the "/ScanControllers.cfm" in the URL with "/isolated/CreateDebugInfo.cfm" and click on the "Create debug file with Controller Info". Email the resulting file to [email protected] I added some debug code to create an empty file with the command about to be executed and then deletes it after executing it.

Pretty significant changes come with beta 6a Updated to support in-window vertical scrolling of both the left side drive list and the right side informational display. Viewing the controller information, display if the drive controller is onboard or what PCI/PCI-e slot the controller card is in on the motherboard Changed how the Benchmark abort button works to accommodate how different browsers render frames Redesign the Rotate option on the Drive Edit text overlay from free-form rotation to 90 degree only Trap errors from lsusb & lspci during hardware scanning Fixed line wrapping of drive selection on the Benchmark Drives screen when the All Drives checkbox is unset Modify the Benchmark submission to pass a SHA1 (non-reverseable encryption) hash of the app's unique installation ID and a compressed MD5 hash of the drive's vendor, model, & serial number to support benchmark recovery and allow your benchmark to compare with others. The Unique Installation ID is derived by taking a SHA1 of the unRAID registration name and a SHA1 of the unRAID registration ID and generating a SHA1 of those two SHA1's For non-unRAID installations, a SHA1 of the Motherboard's Serial ID is used. The compressed MD5 takes each 4 byte block of the MD5 of the drive's Serial Number, converts it from Hex to Dec, and adds all the blocks together. The resulting sum is converted to Base36. It is impossible to derive the original values. Example Installation ID: 1946C31AEEF030DB495B0E13AD1403E9CB0AA7A2 Example Drive ID: 4QJ3 On the first run after upgrading to Beta 6a, all benchmarks will be flagged as not being submitted - so you will get the button to submit them again. This is to allow your Benchmark information to be saved in the new database layout. Benchmark submissions using a version prior to 6a are disabled. Controller information may not display the PCIe slot information on Ryzen systems and report it is an onboard controller. Under investigation.

I've trapped the error being returned by lsusb but working on polishing up a few things. Then I'll be pushing a release to take it out of beta.

I manually ran the sensors-detect packed with the Plugin, no errors, no crashes. No sensors either but that's not it's fault. "sensors -A" invoked by the Plugin does return values. Here's the -u output k10temp-pci-00c3 Adapter: PCI adapter Tdie: temp1_input: 27.750 temp1_max: 70.000 Tctl: temp2_input: 54.750 k10temp-pci-00cb Adapter: PCI adapter Tdie: temp1_input: 27.500 temp1_max: 70.000 Tctl: temp2_input: 54.500

No kaboom.

I made a backup of my Flash, I'll risk it to test that Perl theory.....

Forgot that Nerd Pack now has optional stuff that you have to enable manually in it's settings. Enabled Perl via that method. Went through the same process again with uninstalling the System Temp plugin. No crash but no sensors either. The perl install I found was 5.22 and Nerd Pack has 5.26, I wouldn't think that would have been the root cause since it's fairly close in version.

Typo on Docker/Plugin PLG. I meant Plugin PLG files of course. I'll edit the post to correct that. I had Nerd Pack installed. All plugins were up to date.

Just had a nasty issue with the System Temps plugin that trashed every plugin except the Community Applications (very fortunate). I just replaced my Threadripper CPU cooler so I was curious about system temps running under Unraid. I saw that I had the System Temps plugin installed so I went to it in the settings but it was disabled saying that Perl needed to be installed. I couldn't find Perl in the CA or a link to it in the first post other than it was needed so I went out and got it from https://slackware.pkgs.org/14.2/slackware-x86_64/perl-5.22.2-x86_64-1.txz.html I went back to System Temps and saw that the Detect button was now enabled. Clicking it immediately refreshed the page with nothing apparently happening. Thinking it needed a full refresh, I uninstalled & reinstalled the plugin from CA. I clicked the Detect button and the server hard crashed. No dump log on the console, no blinking cursor. I hit the reset button and when the system came back up, all the PLG files I had installed (15 in all) ended up in plugin-errors as zero byte files. 17 new FSCK00??.REC files in the root directory. I manually reinstalled 14 of the plugins (couldn't find one) and rebooted for posterity. Everything seems to be OK now. Diagnostic file after the first reboot and before I did anything attached. One thing I thought was odd was that when I reinstalled the System Temps plugin, it reported that it updated the support link for it and many other plugins. nas-diagnostics-20181005-1029.zip

Haha! Yup! Though you can click on the drive labels for the SSD's to hide them so the spinners don't look so pathetic in comparison.

That's a good image. I'll save it to add but you can also add & submit images too 👍 If you haven't already done so and you'd like to check out the feature, view the drive with the image you want to update and click on "Edit Drive", then "Upload New Image". Follow the instructions and you're good to go. Since the capacity is on the image, you don't have to worry about the text overlay to add it.

It looks like this might be the source repo. But due to it's age, it might be a clone. https://github.com/zerovm/glibc/blob/master/iconv/gconv.c

Thanks for your help. I won't be able to fix this error but I can trap it.

Are you on DiskSpeed version 5c? If not, upgrade and try again. If you are on the most recent or you updated and still get the error, please do the following: Click on the DiskSpeed Docker icon and select "Console". Enter the following 3 commands: apt-get update apt-get -y upgrade /usr/sbin/update-usbids Close out the console & stop/start the Docker and try again. If it continues to error, I'll add logic to trap this error but it'll either prevent displaying the USB Bus tree or prevent some of it from displaying.

This error is happening in the LSUSB command. Can you enter Terminal mode in the docker (click on the DiskSpeed Docker icon & select "Console") and type in "lsusb -v" and see if it errors? If it does, try it outside of the docker app. Do you have any audio USB devices connected or anything other than keyboard/mouse/drives? (no need for the long java stack trace)

It's been a month or so and I haven't heard of anyone mentioning that this utility isn't detecting their controller and/or drives. Is anyone still having issues in that regard?

The iframe the abort button lives in is big. Thanks for pointing that out. I'll change it so the logic behind it is in a hidden iframe and the abort button itself is not.

Rats. Doesn't look like that worked either, even averaging 400 tests and also going from the end of the drive forward, the timings just aren't accurate enough.

My next project with DiskSpeed will be handy here. Do a full read of the entire drive and graph out on a heat map the amount of data each section reads in 1 second. For example, I start a balls-to-the-wall read of the drive using dd with progress tracking being logged. It reports how many bytes it read each second with the read speed. The number of sectors those blocks will hold the read speed for that second. Then repeat for the next second - and so on. I'll likely do an "overhead" scan where it reads a couple seconds worth over with big gaps in between, like every GB or 100GB, then go through and fill it in. Also trying to programmatically determine how many platters & read heads a drive has. That one has been very elusive. I've tried about five different methods to try to get timings, got one more left to try before calling it quits and using crowd sourcing for populating. Last method to try would be to read the first two sectors of the drive, then move forward one sector and read two, then moving it back one more sector, and continuing until I've stepped over 20 sectors reading two sectors at each spot. Each of these two sector read will be repeated 200 times and the read speed averaged. The thought is that when the sectors are on the same track, they'll give nearly identical speeds but when the sectors span a track requiring the drive head to move, there will be a slight bump. A single platter drive may reveal a spike when reading sectors 1 & 2 (first sector = 0), a dual platter drive with four heads would show a spike at sectors 3 & 4 where a dual platter with 3 heads would show a spike on 2 & 3. *crosses fingers* Hard drives reads all heads on a given track in sequence so if you read 4k of data with 512 byte sectors, it'll read track 0, heads 0-3 in sequence to give you the first 2k of data, then move the drive's head to track 1 and read heads 0-3 again for the next 2k of data.

The SpeedGap logic detects drive activity by comparing the min & max read speeds. If the difference exceeded the threshold, it increases the threshold a little bit and then retests it. If you were getting wildly varying results, that would explain why you had to disable it to even finish the drive. It looks like there's a LOT of coverage that's giving varying read issues. Kick off a benchmark from the main screen and select the drive in question and another drive on the same controller but do not disable the SpeedGap logic. When the benchmark starts, you'll see the following under the graphs: "Click on a drive label to hide or show it." - the period at the end is a hidden mouse click trigger to unhide the iframes that are running the tests. It'll let you see what the SpeedGap detection is finding.