• Posts

  • Joined

  • Last visited

Recent Profile Visitors

1153 profile views

b3rs3rk's Achievements


Explorer (4/14)



  1. Correct. The card is no longer visible to the nvidia-smi utility so the plugin cannot retrieve data from it.
  2. There is nothing in my plugin that would or could prevent UnRAID from booting. If you didn't choose a vendor, at worst the dashboard page would render a blank widget.
  3. Having trouble understanding your first sentence. Is this the first time you are using the plugin? Have you at least once clicked 'Apply' at the bottom of the settings page? Show me the contents of your config file: more /boot/config/plugins/gpustat/gpustat.cfg
  4. If you just changed cards, you need to change a setting with the new card selected and actually click Apply. I'm betting your config still has the GUID from the previous card you had installed.
  5. At this point, it might be beneficial if we could set up a screen share session. Otherwise it is going to be a PITA to send you all the debugging changes to find the root of the problem.
  6. If you can, open an issue on GitHub and I'll push some kind of fix in the next release.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Answered ad infinitum in this thread. One day I hope to implement it, but I just don't have time right now.
  14. 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.
  15. 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.