b3rs3rk

Okay so your iGPU is not being inventoried at all. Can you do an: lspci | grep VGA and paste the result? I looked at the output in your diagnostics file but want to make sure. Beyond that we will have to do more debugging to discover the root cause.

I guess it isn't detecting your iGPU when the settings page is running the inventory code. I looked at the lspci dump in the diagnostics and I pulled the line out that should be returned and tested it against the inventory regex for Intel and it matches with no issue. So I'm at a loss without more troubleshooting. Easiest way, would be to edit the /usr/local/emhttp/plugins/gpustat/gpustatus.php file to force a data dump for review. Run it line by line. cd /usr/local/emhttp/plugins/gpustat sed -i.bak '44 c\$gpustat_inventory = true;' gpustatus.php sed -i '52 c\var_dump($gpustat_data);' gpustatus.php php gpustatus.php <data that we need to see> ### Revert cp gpustatus.php.bak gpustatus.php rm gpustatus.php.bak

Emby was originally included in the app detection when it released, but was disabled due to the large number of false positives where it was identified as running when people didn't even have an Emby container running. This is because it invokes 'ffmpeg' as the process with no other determining language in the command to accurately identify it as Emby. Because the issue creator (for issue #32 on my GH repo that you referenced) included a command/process name that included the string 'emby' I decided to re-activate it using that command syntax. If the container you're using doesn't use the same command, it won't work. You could try reaching out to that user and see which container they are running and follow suit. Or someone could request that the container authors they prefer use a predictable command for their transcoding processes.

I'd consider implementing something like that if it was a desired enough feature, but you're the only person that has requested that functionality before (I think). Have you tried filing an issue with the application or container image author to start using a more deterministic command to launch their ffmpeg processes? I looked at the Tdarr Dockerfile and they actually install jellyfin-ffmpeg via APT and create a symbolic link to /usr/local/bin/ffmpeg. If they just named it tdarr-ffmpeg we wouldn't be having this conversation.

IMC bandwidth is specific to Intel iGPUs and usually works fine but it really depends on the CPU/GPU package. I can't use those diagnostics to determine the issue, but the way the code is written, the IMC Bandwidth usage will return N/A if intel_gpu_top is not returning those indexes in the statistics pull. Try this from CLI: timeout -k .500 .400 intel_gpu_top -J -s 250 And post the result here.

If Nvidia-smi says no processes are found you are not using it. Nothing else to say really. The plugin is not magic, it depends on nvidia-smi reporting to populate the widget.

Answered ad infinitum in this thread. One day I hope to implement it, but I just don't have time right now.

App detection isn't that straight forward. Depending upon the container and/or the configuration you're running tdarr may be using ffmpeg or HandbrakeCLI in such a way that we can't determine tdarr is invoking it. Nvidia-smi usually only reports a single binary name (like "ffmpeg" or "HandbrakeCLI") as the process that's using the GPU. Some applications are much more specific. Plex, for example, doesn't just invoke ffmpeg, it invokes its own "Plex Transcoder" process that is easy to identify. Still, I do attempt to pull the full command of the process using the PID Nvidia reports, but if I don't find "tdarr" anywhere in the command I can't rightly match it. I'd investigate your own processes when Tdarr is running and see if there is any way to uniquely identify it and then let me know. Otherwise, can't fix it.

PHP gets a lot of hate. And it should. It's terrible. I mean, just awful when you compare it to so many other languages. But it's what I cut my teeth on when I first started programming so it will always have a fond place in my heart. I merged the PR today, will try to get it released today or tomorrow. I'll also finish what I've started in the new branch and commit it if you're intent on looking at it. My weakness is web stuff. I'm not in any way a front end guy so the concept of CSS just eludes me.

Not a complete re-write, just the settings stuff. The code needs to be setup to be iterated for each additional card the user wants to display. That in itself is pretty simple. What is a bit more difficult is re-designing the way a user configures the settings and how those settings get written to the configuration file as it is only setup to accept a single set of values for a single chosen vendor. You and I both know that nine times out of ten when a user has an issue it is because of some setting being set incorrectly or because an update didn't populate the file properly. So care must be taken when touching that piece of it or else we will be overwhelmed with complaints. And not just our favorite "My graphics card is old enough to operate a motor vehicle but it doesn't show anything on the dashboard, what gives?" complaint. I have a branch for doing exactly this, but I've taken on a lot of duties at work and have had little time for implementing it. @SimonF gave me a bunch of pointers on how to do some of it but I can't seem to find the time. I could probably rush something out, but I guarantee I would be inundated with requests to support everyone's edge use case. I also don't really have a dev/test box that I can push these changes to that has multiple GPUs installed. Which would be extremely helpful in reducing initial bugs. @corgan I reviewed the PR. You just need to change the file casing for the nsfminer image in code and the filename itself and I will merge. Thanks for the contribution!

This has been discussed many times within this thread. Please search and find info/potential fixes provided by myself and @ich777 -- it is not a bug on my part, but has to do with something specific to your hardware configuration.

No need to paste the result of this unless it gives an error: nvidia-smi -q -x -g GPU-5ca972bd-e20a-d575-d786-92a6666edc88 Just want to confirm your nvidia-smi polling works with the configured GUID. You are missing some configuration settings, but they are the ones for the AMD monitoring and shouldn't have any effect. Still, might try to remove and reinstall the plugin completely (including deleting the /boot/config/plugins/gpustat directory after uninstalling the plugin from the UnRAID UI). EDIT: This is the problem. Based on your previous screenshots, the GPU GUID in your config file is different from the one you posted for @ich777 from the settings page. You need to re-save your settings especially when switching cards. I'm guessing you replaced your old GPU with a new one and the GUID of the old one is still saved.

@mihcox Could you show me the contents of your gpustat.cfg in /boot/config/plugins/gpustat

@mihcox That's all valid XML, and should meet all the criteria my code requires to not hit the error you're getting. Something else must be going on. Try this: php -r 'var_dump(@simplexml_load_string(shell_exec("nvidia-smi -q -x -i 0")));'

@Tibbe Even though most of the monitoring was deprecated by Nvidia for your card, the dashboard should be showing a few metrics for you. Temperature, fan usage, power state and maybe memory usage. It will never show GPU or Encoder/Decoder utilization, so I don't know how useful the plugin will be. But something is happening where my code isn't receiving valid XML or it can't find the main element it wants. Can I see your config file?

nvidia-smi -q -x -i 0

I have reviewed your PR. Please check that out when you have the chance. The work looks fine, just need a couple things changed and the PR re-opened to the dev branch. There are ways to determine what is calling the ffmpeg process. I do that for deepstack because nvidia-smi only shows python3 is running. I dig out the PID info, check some of the extended information and make a positive match that way. Might be doable with whatever third application you wanted to add as well. As for your stats not showing up for your AMD card the GPUID setting in your config file needs to reflect the BUS ID of the AMD device. Yours is still showing the UUID for your Nvidia card which will cause it to fail. Probably a bug on my part but this is likely caused by you switching back and forth.

Some kind of error when the actual statistics collection process is triggered which is returning no data or an empty array most likely. Please read the first post of this thread and include the result of the troubleshooting step that involves running the PHP script from the CLI. I'm not going to copy paste it for everyone that chooses not to read it. Hint: It is Step 2.

Hey folks. I just upgraded my UnRAID server to use a new SuperMicro board and am trying to get the IPMI tools working properly. It identifies the SuperMicro IPMI branding and can read all of the sensors without issue. But I'm having an issue with actually changing anything in the config. Any change on any tab I make is ignored even after clicking Apply, then Done. When I go back to the IPMI settings page it is all set to the defaults again. I tried searching in this thread but didn't see anything about a config not being saved. When looking at the Firefox console, I'm seeing a DOMException whenever I browse to the IPMI settings page. The function that is throwing the exception is this one: function decData() { $('#PASSWORD').val(atob($('#PASSWORD').val())); } Not sure if that is the reason things are not working for me, but it's the only error I see when attempting to make changes/save the config. I had previously been using AutoFan and System Temp plugins from Dynamix, but I removed them just in case they were causing issues. They are pretty much worthless now anyways since everything is handled via IPMI on this board. Specs: UnRAID 6.9.2 Pro Xeon Silver 4110 SuperMicro X11SPL-F Motherboard BIOS Version: 3.4 (Latest) BMC Firmware Version: 1.73.05 (Latest) EDIT: It seems that even though I had the Network Connections set to No, it was still trying to autofill my UnRAID user/pass in the BMC connection and submitting it whenever I clicked apply for unrelated settings. After disabling autofill for the UnRAID site in Firefox I was able to make changes.

Beyond the multiple vendor support that was somewhat recently implemented (added Intel and AMD) this is probably the most requested feature. I think I know what needs to be done to address this after talking with some other community devs but it will take time to implement. I'm limited in what I can test because I have a single GPU setup with no onboard graphics because I'm using Xeon. Makes it difficult to start poking around with it too. Trust me, it's on the horizon just no ETA yet.

I'm pretty sure it was just an issue with the settings not getting saved. Maybe. I didn't point you to the correct location for the real plugin config the first time so it is hard to say.

lol, I know. I had you put in a debug on Line 287 of the lib/Nvidia.php file that is probably still there causing the script to exit. You can either reinstall the plugin or make that line blank again.

Is it updating the cfg file? Without that being updated it won't work. Check your boot plugin config file, I just realized you might be looking at the default.cfg which is my fault. more /boot/config/plugins/gpustat/gpustat.cfg

I might have a defaults problem somewhere in the Settings page. But it should be working now after you applied it?

I mean, you probably could. But I'm really not sure what could be wrong with the settings creation. Make sure everything looks like this then click Apply at the bottom of the page. If the Apply button is greyed out and you can't click it then it won't work. You have to change something to get it to switch. EDIT: Greyed out -- Changes detected --